daily articles for founders

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

How not to recruit cofounders  

Like many other technical people with startup experience, Tristan Kromer gets approached by non-technical founders and is tired of people making basic mistakes in their pitch to him. Here's his list of don't's when approaching a technical cofounder:

  • Don't bullshit. If you don't know, say so.
  • Have more than an idea to offer.
  • Don't ask for an NDA.
  • Be clear. If you can't be clear even this early in the relationship, working with you will be a hassle.
  • Show that you can do it by yourself.
  • Know your metrics.
  • Don't make up words to describe your way of working.
  • Don't negotiate about share percentages.

The last point is interesting:

If you offer me 1% of the equity, I'll do 1% of the work. If you offer me 25% percent, I'll do 25%. If you offer me 60%, I'll insist on only taking 25% and I'll work 24/7 for you.

It's a bit tongue-in-cheek, but makes the point that if you're arguing about percentage points already this early in the startup, chances are the relationship will struggle. If you want to encourage loyalty, err towards generosity (but only with committed cofounders).

Building a viable business in 4 months  

This anonymous reddit poster built a viable business turning over $150k/year and making $1k/week of profit, in 4 months.

Then he decided to post an AMA (Ask Me Anything) on Reddit.

Worth a good read, and worth noting once again that building a profitable business and building a hot new startup can be completely orthogonal activities. Maids In Black applies a lot of the tools of the startup world (glossy design, cool attitude, differentiated service, etc) to a domain that many hackers would consider beneath them. The result for the entrepreneur is not beneath most hackers, though: he's doubled his salary and is planning to quit his job in 4 months, once he has paid up his debt.

Have a read for yourself.

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.

How to develop disruptive ideas  

Great article from Luke Williams, the author of Disrupt, about how to develop disruptive ideas:

Most people in business are trained to focus only on problems: things that don't work and need fixing. It's more effective to start by identifying something in your business or industry that's not necessarily a problem, and then go about methodically breaking it down using the following steps.

Luke proposes 3 steps:

  1. Define the domain you want to disrupt; this should be a domain where things have been stagnant for some time.
  2. Find the business clichés; figure out the assumptions that everyone in the industry makes.
  3. Start overturning those assumptions: ask "What would happen if we _ _ _ _ _ _ ?" where _ _ _ _ _ _ is something that the industry takes for granted.

Luke provides examples too:

Let's look at the soda industry. Inverting "soda is inexpensive," gives you "soda is expensive." Reversing "tastes good" gives you "tastes terrible," both of which sound completely ridiculous. But, you can't break the clichés without going through this step, which is exactly what Red Bull did. It placed absolutely no importance on taste, the product is double the price of Coca-Cola, and it dispensed with marketing aspirational images. The message was that Red Bull may not necessarily make you feel happy, but it'll definitely give you a shot of energy when you need it.

The article is worth a read (and maybe the book too).

Zombie Startups  

Danielle Morill:

My greatest fear as a startup founder isn't to fail, it is to become a zombie startup. Kind of like in the 6th Sense when Bruce Willis doesn't realize he is dead and tries to have a nice dinner with his wife, there are startups out there who are still "operating" but might as well not be.


The first thing you need to do is acknowledge the reality of your situation. From there, figuring out what to do next is a lot harder and a very personal and contextual decision, but you should embrace it with vigor. Don't waste single moment of your life, or the time of those on your team, to begin plotting the next step.

Danielle also points out that if your startup has failed, hard, don't shy away from calling it a failure and moving on.

Remember: impatience kills startups, but patience kills human beings.

Side projects  

Andrew Dumont makes an interesting point:

Know that when you start just a side project, you're starting so much more. It'll completely consume you. The worst failure in any side project is to devote time, energy and sanity for any sustained period only to close the doors.

Side projects are a means to an end.

They need to start with an end-state in mind - create a passive income stream, validate my idea. They need to have deadlines and key metrics - six months to profitability, 10 paying users to validate my idea. But most importantly, they need to be a sprint. The longer a project lingers, the harder it becomes to keep morale high and pull the plug if it's not working out.

There is, of course, a valid point there. Then again, I am reminded of those people who assault young musicians with questions like "But why do you want to play the violin? What are you trying to achieve?"

Isn't playing violin and starting side-projects just for the fun of it enough for a start?

I am pretty sure that most people who eventually started side projects with clear end-states in mind first started side-projects just for the heck of it. They probably did that for years before the thought that a side-project could have an end-state right from the beginning entered their mind. That certainly was the case for me: most of my early programming, writing or web activities were done purely for the heck of it.

So, perhaps better advice is to be aware that some day you will want to graduate to definite goals.

But if you want to start a side-project today for the heck of it? Go for it.

Focus and myopia  

Here's a really excellent article by Dharmesh Shah that deconstructs the glib advice that "focus is key":

So, here's my point: Talking about focus is useless unless you consider the level of abstraction you're talking about. If you squint just right, any activity you're looking at seems de-focused. In the iPod example above, I could argue that Apple showed considerable restraint and focus by not going out and building a Hollywood production studio and creating content. Or, I could argue the flip-side and say they lost focus from their core.

I agree that focus is about saying no. But that's not all of it. By saying no repeatedly, what you're buying yourself is the ability to say yes to something much, much better. You're not freeing up resources just to hoard them away. You're freeing them up so you can apply them better — either by saying "yes" to something new or doubling-down on bets you've already made. So, the benefit of saying no to a bunch of wrong things is only realized when you find a way to say yes to the right thing. Important note: I'm primarily talking here about high-level company strategy. If we were talking about focus as it applies to product management, saying "no" to new features has intrinsic value by just keeping things simple.

Advice is always highly contextual, and most people don't take the time to figure out whether their context is right for the advice they're looking to apply. This type of article is very useful in that it takes an apparent truism and shows how variable it is.

After all, the opposite of every profound truth is another profound truth (Niels Bohr), so unless you know how to apply profound truths usefully, they can hurt you as much as help you.

Read the whole article here.

Driving, and the art of running a business

Learning to drive and learning to run a business are surprisingly similar endeavours.

When you learn to drive, you don't know what you need to pay attention to. There are, seemingly, a million things going on, and some of them might kill you if you fail to heed them. This can cause a sense of panic in the beginner. When you know how to drive, you rely your experience to know what to pay attention to and what you can simply ignore or deal with without thinking about it.

Learning to run a business is similar. There are a million things that you could do, and some of them will kill your business if you fail to heed them. This can cause a sense of panic in the beginner. When you know how to run a business, you rely on your experience to tell you what you need to pay attention to and what you can simply ignore, delegate or outsource.

When you learn to drive, there are a lot of new habits that you need to build into automatisms. Learning to use the clutch to change gears rapidly while accelerating onto the motorway, surrounded by speeding cars, seems very difficult at first. But the more you do those things, the more they become automatic and unconscious. When you know how to drive, you don't even really think about changing gears, you just do it.

Learning to run a business is similar. There are a lot of new habits that you need to build into automatisms. Learning to detect that the person in front of you is a lead, pitch them in the correct way, follow up, and close the sale, seems very difficult at first. But the more you do it, the more it becomes automatic and unconscious. When you know how to run a business, you don't really think about pitching and closing sales, you just do it.

To learn to drive, you have to actually sit in a car and drive yourself. No amount of reading or talking about it will enable you to drive. You could study driving for years, and even watch someone else driving for years (most of us watch our parents driving for our entire childhood), and still it won't replace the actual experience of driving. While it is possible to build car simulator, even that is a poor substitute for actual driving.

Learning to run a business is similar. You have to actually run a real business yourself. No amount of reading or talking about it will enable you to run a business. You can do all the MBAs you want, and study entrepreneurs and entrepreneurship for years, and still it won't replace the actual experience of running a business. While it is theoretically possible to build a simulation of a business, it's a poor substitute for actually running a business.

The best approach for learning to drive is to get an experienced driving instructor who will sit in the car with you and figure out what you know and what you need to learn, construct a teaching plan personalised to you, teach you those things, demonstrate them when it helps, and help you practice them over and over again in a safe environment, watching out for things that might kill you. Because this approach works, it is used throughout the world.

The best approach for learning to run a business is similar. You get an experienced mentor or coach or close advisor who will be lightly involved in the business, who will figure out what you really need to know next and point you in that direction, who helps you work through tricky business issues, and who watches out for things that might kill your business and that you haven't spotted. This is much less widely used in business than indriving, perhaps because good business coaches are much more rare than good driving instructors. But driving schools for business are getting more common every day.

There is a difference between learning to drive and learning to run a business. In business, there is no such thing as a safe environment. You're on the motorway from day one. And most people drive their first business without an instructor by their side.

Recruiting in the Valley: the recruiter honeypot  

Elaine Wherry has written a detailed analysis of recruiting in the Valley. If you're based anywhere else, it may be of mostly intellectual interest, but if you're competing for developers there, it seems like a must-read - and highly entertaining, too.

The honeypot idea emerged slowly, "If only I weren't a founder! Which recruiters would have contacted me as an engineer?" I stewed on the idea of posting my resume online with a fictitious name for days and then one sleepless night, without telling anyone, I woke up and posted a small three-page website with an about page, resume, and blog for a supposed Pete London whose interests and engineering persona mirrored my own except he wasn't a founder. I swapped out my post-graduate experience with my husband so it wouldn't be too easy to trace back to me. I returned to bed with a small glimmer of hope - I had been hunting for recruiters for months but now the recruiters would come to me!

Elaine goes on to break down and analyse the data she has gathered, and derive some solid actionable tips for startups who need to hire. Read it here.

Stealth mode startups  

Mostly correct advice, for most cases, to startups in stealth mode:

... stop being in stealth mode. Stop asking for advice. Stop doing your start-up. You're not ready.

Jason Freedman of HumbledMBA proposes these key reasons why you should never be in stealth mode:

  1. Execution is more important than the idea;
  2. Someone else has the exact same idea anyway;
  3. Completely unique ideas generally don't make it;
  4. The most likely cause of failure is your incompetence, not the competition;
  5. You desperately need real feedback;
  6. First mover advantage is just silliness.

Another side-effect, perhaps less important, of stealth mode, is that people you meet in networking events will think you're a startup newbie (and they'll probably be right). You won't get the same level of introductions, because who wants to risk their reputation introducing someone who doesn't even know the basics of startups? Instead, you'll get lots of advice about why you shouldn't be in stealth mode.

My first startup was involuntarily a stealth startup. We didn't tell anyone other than friends because we didn't think it was that important, and we wanted to build a sense of excitement around the launch. It was one of the main reasons the product stank at launch.

If you don't get user feedback from the right people during product development, your product will suck. That was lesson from startup number 2. It's not enough to get feedback, you need feedback from paying users, as soon as you possibly can, or else your product development bus will drive down the wrong road, and it's damn hard to turn it around later.

There's always a caveat, though, always a context where this doesn't work. I believe it works for most web startups, but in other industries, stealth mode may be de rigueur.