daily articles for founders

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

Recruiting programmers to your startup  

Another excellent article by Chris Dixon, about a topic that is important to pretty much every startup, no matter what your definition of the word.

Chris's key points can be summarised as:

  • Understand what motivates programmers (beyond a certain point, it's not money)
  • Respect programming as the creative activity it is
  • Be proactive about building contacts with great programmers
  • Use various cues for screening and filtering down candidates, like open source contributions, code tests, and trial projects
  • You'll need a track record of treating programmers well to be able to attract great programmers who have many other options
  • Don't try to beat Google on perks, you can't
  • Don't under-grant equity to early programmers who join you before you've achieved traction - they are late cofounders, not early hires

Great points. I'll add that one of the things that can really help with telling great programmers apart from not-so-great ones is, in fact, to have a great programmer on your team already. It takes one to know one.

Getting into a startup right after university  

Some great tips by Jean Hsu. Startups won't hire fresh graduates on the basis that "they can do the job already". They will hire on the basis of potential. It is understood that it will take time and training to grow a new graduate into a fully productive hire (and that, largely, is why graduates make less money than experienced hires).

Here are Jean's tips:

  1. Try to get personal recommendations, by letting your friends know you're looking for a startup job, and going to relevant meetups and events.
  2. Tailor your resumé to the job you're applying for.
  3. List extra-curricular projects. In my opinion, those are often much more interesting and convincing than anything you may have done in class.
  4. Have an online presence so you stand out.
  5. Prepare for the interview by reading up on the startup and familiarising yourself with the product.
  6. Be relaxed, friendly, comfortable (be yourself!) during the interview - they're not just testing you on your technical ability, they also want to check they can work with you day in day out.

Don't forget to evaluate whether you want to work at that startup. For a new graduate, the calculation is slightly different, in that almost any job will teach you a lot, but don't let yourself stagnate during your first few years out of university - they are possibly the most important of your career, in terms of their potential to set your direction for the next 10, 20 years.

The main advantage of a startup job for a college graduate is that you will be able to grow into a position of responsibility much, much faster than at a larger company - but you do need to go about it deliberately to make the most of it.

Another piece of advice: if the "startup" turns out to be nothing like what it advertised itself as (some people are unscrupulous about calling their small businesses startups), leave quickly! The personal growth opportunities in a small business which isn't growing are usually extremely limited.

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.

Bootstrapping on the side  

Joel Gascoigne proposes a method for working on a startup while busy doing something else (a full-time job to pay the bills, for example). He doesn't mention too many details of actual method, but one of his methods seems to be to do something every day to push the startup forward, no matter how small.

This is definitely a good method to build your startup if you have no other choices (which is the case for most), and I agree with Joel that it is better than his previously described "working in waves" method.

However, he is too quick to discard the potential for losing to faster competition:

On top of that, let yourself succumb to the myth that you can be killed by your competition and you're in for a tough ride.

This really depends on what kind of product you're building. It's sound advice only in the sense that if you're building a winner-takes-all, high profile product, you shouldn't be bootstrapping anyway.

Idea reach and the cofounder myth

Last week's linked post "stop looking for a cofounder" generated quite a bit of response on HN, much of it around the idea of using freelancers to build your startup. People seemed to think that I advocated using subcontractors to build high-tech startups.

The answer to this is a concept I call "idea reach", which is essential for any new entrepreneur to understand, especially if they think they need a cofounder.

The ideas within your reach

Idea reach represents the landscape of ideas that are within your reach to implement. On the multi-dimensional mental map of startup ideas, it is the ones that are close enough to your current location (determined by your knowledge, personality, experience, etc) that you can actually get there (with the execution ability you have - determined by your resources and skills) and implement them. When evaluating which ideas to work on, you should always consider this concept. One of the reasons why so many business cofounders are "looking for technical cofounders" at the wrong time is because they fail to understand idea reach.

There are many bad, good, and great ideas out there. When deciding which one to work on, it's not enough to evaluate whether the idea is viable in the abstract. Whether you personally will be able to execute on it is just as important.


Here are some simple examples.

Let's say you had the idea of using popularity to rank webpages, back in the late 90s, but you have no technical background. You don't know programming, you just know how to use a web browser and create a Geocities page, but you think that search engines could be done much better.

This is a brilliant idea, and after you explore it (using, for example, the lean methods which only evolved 10 years later, because you're a visionary), you decide that this is worth pursuing, it has a lot of market potential. And you would be right - that idea turned out to be one of the biggest ideas of the decade, spawning the extremely successful Google.

However, starting with no technical knowledge, implementing Google would not be within your reach. It's a great idea for somebody else, someone who has the technical chops to implement a highly challenging technology project like the Google search engine. It is not the kind of idea where you can just put down a few hundred thousand dollars (assuming you had them), hire a bunch of programmers, and get them to make it happen.

Another, even more obvious example: let's say you have an idea for a phone better than the iPhone. Let's assume it's a great idea, and you even have the skills in "technology" to implement it (yes, I know that it's laughable to think that a single person could do all that today). That's still not within your reach, however, because developing an iPhone-killer prototype is far from sufficient to compete with the behemoths operating in that market. You need logistics, manufacturing deals, negotiation leverage, great marketing, and so on. There's no way you will have access to that without first building a large company. This idea is obviously out of the reach of any new entrepreneur.

Here's a more subtle example: let's say you know very little about software, but you are a highly experienced project manager and you think you can design significantly better project management software. Depending on how complicated this software is technologically (and to find that out, you'll have to trust someone technical to tell you) this idea may be just within your reach (with some hired assistance), or just out of your reach.

If the tool turns out to be relatively simple (bearing in mind that not everyone is trying to build the next Google), and if, as the founder of the company, you have the funds (from whatever source) to invest in it, it is conceivable that an early version of this project management tool could be implemented by freelancers, paid employees, or a combination of the two, without you, the founder, having to be technical. So long as the idea is not too technically complex (and a lot of great business ideas aren't very complex technologically - e.g. Groupon), you can make up for your lack of skill by spending money.

If it turns out to be very complicated, the idea is simply outside of the reach of a non-technical project manager. It might (or might not) be a great idea, but it's not the right idea for this founder. Instead of looking for a technical cofounder who will make up for that huge hole in your skill set, find another idea that's better suited to you.

Finally, if the idea is not too technical, so it is possible to hire people to do it for you, for a sum anywhere from a few thousand bucks to a million, but you don't have that money available, then no matter how simple the idea may be, it is out of your reach, because you do not have the resources to execute on it. At that point, you shouldn't "go looking for a cofounder". Instead, try to raise the capital (likely from your own savings) so that the idea comes within your reach. If you can't raise the capital (because no investor believes in you, or because the idea is just too expensive), this idea is outside your reach. Do something else.

The problem with looking for cofounders

The way many people end up looking for cofounders is that they spend a lot of time thinking through a lot of ideas, and finally settle on the "best" idea that seems not too far out of their reach. Very often, however, that idea is still quite far out of their reach, usually because they lack the technical skills to implement it themselves and they vastly underestimate (or don't bother estimating at all) the complexity of the idea.

So then, having had the idea already, they go and look for a "cofounder" to make up for the fact that this not the right idea for them. Sometimes, they find that person. Sometimes that even works out ok. But generally, it doesn't work, because the people who make good cofounders are either unavailable, or uninterested in your idea, and so the chances are anyone you do convince to join you isn't worth having as a cofounder in the first place.

Extending your reach

This, however, doesn't mean that there's anything wrong with having cofounders. Cofounders provide many things, including motivation, more dynamic ideas, and even additional reach. If you know someone who is great at building physical widgets, and you're great at building software, and you're both looking to start a business at the same time, it can very well make sense to team up and look for an idea that's within the reach of both of you as a team, rather than individually. Chances are, this idea will have less competition, because fewer founding teams will have those combined skills.

"Looking for potential cofounders" is fine if your aim is to meet cool people whom you may want to work with later if the right opportunity comes along. Having great people in your network extends your reach because if you both happen to be free at the same time, you can pool your resources and execute on more difficult ideas.

But don't go looking for a cofounder to enable you to implement an idea, which you've settled on already, that's outside your reach. That's not a cofounder, it's an employee who's executing on your plan, and should be paid with money. And if you can't afford them, or if the idea can't be implemented by hired guns, then find another idea. It's not like there's a scarcity of ideas out there.

Swinging for the fences

One last thought. A lot of people will respond that many highly successful startups implemented ideas that were outside their reach, and succeeded anyway. YCombinator has made it a successful business model to take founders and virtually catapult them far away from their idea reach, and succeed anyway through a combination of exceptional founder selection and world-class mentoring.

That's a fine business model for YC, a great thing for the world to have, and if you're one of their selected protégés, you should definitely go for it and give it your best. However, this type of proposition is always, naturally more risky. If you can afford to fail without too much damage, swinging for the fences may be the right strategy for you (see this article too). If, however, you've got very limited savings, and failure will propel you back into a corporate environment and a job you hate, then it might be better to focus on achieving survival and comfort first. That's easier with an idea that's within your reach.

How to get a job at a startup if you aren't a developer  

Some solid advice from Eric Stromberg. In short:

  1. Know the tech landscape better than anybody else.
  2. Form an opinion and start a blog.
  3. Be familiar with the startup culture.
  4. Offer a concrete skill.
  5. Take an internship.
  6. Send cold emails.
  7. Understand that most people get non-technical jobs at startups through their network, not job postings.
When do you kill your startup?  

Ryan Carson:

After a lot of soul searching I decided to take Option #6 and kill the product. I could've figured out a way to make options 1-5 work if I truly believed in the product and it's mission. Deep down though, sending large files wasn't something I was truly passionate about.

Founder-product fit is a bitch. If you're not enthusiastic (and I mean really enthusiastic) about some fundamental aspect of the product you're delivering, it's not a good product for you.

However, to answer the title question, when should you kill your startup? Probably a lot sooner than you think. Some entrepreneurs give up too early, but they are rare. Most tend to give up far too late - and when they finally throw in the towel and start something new (which is a lot more exciting and fun than flogging a moribund horse), they usually feel relief that they finally made the decision, and regret that they didn't make it sooner.

If you're asking yourself whether you should kill your startup, you probably should kill your startup.

How to handle lawyers threatening you  

Excellent article by someone who clearly has a fair bit of experience being threatened by lawyers. This is something that can happen to any business, particularly a successful business.

In short, Judd Weiss outlines three examples of his approach:

The more threatening the letter, the more references to precedent case numbers, the more terrifying the tone, the more they're covering up. The more they are compensating for lack of a legitimate case. Learn to smell a bluff.

When being bluffed, Judd's approach depends on the attorney's tone on the phone when he calls them. Reasonable, friendly sounding attorneys get dealt with reasonably. "Cold and technical" attorneys get served with:

The letter I received is without any merit whatsoever. You've given us 1 month to send your client $350,000 before you file a lawsuit. That's nice of you, but let's not drag this out and create movie suspense. Go ahead and file the suit tomorrow if that's in your client's best interest. But if I receive any more communication from your office beyond that this matter is dropped, I will sue your client and sue you personally for malicious prosecution according to CCP 128.7.

Finally, some attorneys are rude, nasty and condescending, and Judd deals with them by providing them with an answer they cannot seriously take back to their client without looking stupid.

Hacker News comments on the article are worth reading if you want to know more about this topic, as this approach will only work in the right context.

Gabriel Weinberg on raising VC money  

Great article by Gabriel. It claims to be really long, and it is quite long, but it's also extremely concise, and well worth your time.

Here's the super-short ultra-summary - basically just the headlines:

  • The funding process is not to be taken lightly.
  • Save up good news for the middle of the process.
  • People would talk to me because of traction and track record.
  • We probably could have raised earlier.
  • There are a lot of VCs.
  • Your VC is essentially buying in as a co-founder.
  • It's good to know people ahead of time.
  • To blast or not to blast.
  • Don't pitch ideal VCs first because you'll mess them up.
  • Get your story straight.
  • It's awkward to pitch people you know, but give them the real pitch.
  • Use AngelList.
  • Intro channel breakdown.
  • Getting to the right partner initially really really matters.
  • Often times the right partner is unclear without talking to someone else.
  • Having a good network to get intros really matters.
  • A warm intro >> cold intro.
  • Principal intro is OK if not right partner intro.
  • I never walked through my 6 slides.
  • I got very few NOs.
  • Having multiple term sheets really matters.
  • Blasting matters to align time-lines.
  • VCs really do take vacations in August.
  • Some partners I really liked.
  • I did not push for a bidding war.
  • I focused on what value the VC would bring.
  • I did reference checks.
  • I didn't travel much.
  • Having a mentor really helped.
  • Congratulations.

Go read it now.

Tech founder's guide for picking a non-tech founder  

Jessica Alter:

There are many articles and blogs claiming to have THE list of things to do to find the perfect technical cofounder - as if it's that easy to find a cofounder in general. From my purview at FounderDating, however, one of the most important and least-discussed (in the press, at least) questions is from technical entrepreneurs. For the last year the longest- running trending topic on FD:Discuss (the Q/A section of the site) is: how do technical cofounders evaluate non-technical cofounders?

Jessica outlines 4 key criteria:

  1. Good at figuring stuff out
  2. Good at getting stuff done
  3. Highly determined
  4. Good at communication

Ultimately, the kicker is in Jessica's suggestion as to what to do to recognise those characteristics in a potential cofounder:

Start a side-project. These quotients are exponentially easier to calculate when you're working on something real together. It doesn't matter if it's the idea you actually end up working on, you'll see far more revealed doing this than you will over 10 coffees or hypothetical white board sessions. Yes, that also means you can't find the right partner in just a few weeks. So be constantly putting yourself out there.

A few months seems about right. Remember: finding a cofounder is like finding a wife. You don't go out looking for a cofounder, you go out to meet new people and work on neat projects with them, and if you meet one that you feel like starting a company with, great.