daily articles for founders

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

Why Ty Danco is investing in CardMunch  

An excellent dive into the mind of an angel investor, and how he perceives and analyses deals:

There are just 3 inviolate areas for any investment: 1) A large, addressable market; 2) a capital efficient business model which can create good margins; and 3) great people. The first two I don’t even have to consider carefully—you can normally disqualify a deal that doesn’t cut it in less than a 2 minutes. But most everything else takes some time. My rough weights are as follows:

10% Product: (with at least a beta product up and testable)

60% People: Who is the team? (Past experience, past SUCCESSFUL experience, technical chops, hunger, humility, coachability, advisory boards) Do I believe the CEO? Do I like them?

10% Distribution: Who’s leading sales? Can they sell at the Startup (as opposed to Big Industry Leader) level? How will they reach customers? Also pricing, sales cycle, staffing requirements, etc.

5% Operations: Is this scalable? Tested technology? Dependable outsourced vendors?

5% Social proof: Who else is investing, and do they bring anything besides money?

5% Price and Terms

5% Everything Else

Worth a careful read if you're thinking of raising money.

How to evaluate and implement startup ideas using Hypothesis Driven Development

So you've come up with an interesting idea. You think it might work. You've sketched it out using various tools like the Business model generation canvas, a business plan, an Excel financial model, etc. You're still positive on the idea and think it's probably worth giving it a shot.

What next?

One common approach is to visualise launch day and work back from there. Figure out what you need to launch some kind of initial product, and then start casting the spells and incantations required to get there (mostly in the form of code or application specifications).

A slightly better approach, which those who have tried the above method usually end up using next, after they built something that took them 6 months but was utterly useless to anyone, is to build the bare minimum that you need in order to get some users, any users, to use the system on a regular basis. This is better, and gets you feedback much more quickly than the previous method.

Even better is to aim not for something you can get people to use, but instead try to build something you can charge for immediately, even if the price is lower. This is often favoured by Lean Startup afficionados who haven't quite taken the lean methodology the whole way yet.

What do all these methods have in common? They present the unfolding startup as a series of tasks to be completed to get somewhere.

Here's a better approach.

Hypothesis-Driven Development

A startup idea is not a plan of action. A startup idea is a series of unchecked hypotheses. In essence, it is a series of questions that you haven't completely answered yet. The process of progressing a startup from idea to functioning business is the process of answering these questions, of validating these hypotheses.

Let's consider a theoretical startup to illustrate this. Let's say we're looking at building "Heroku for Django". The initial three questions for most web startups will be in the form:

  • Can I actually build it?
  • Can I get people to know about it?
  • Can I make money from it?

Often, this is the order in which they will arise, if you have some experience of web startups but are fundamentally a builder type. Making money is the last concern. "If I can get lots of passionate users who are willing to pay something, then it will probably be alright."

To apply Hypothesis-driven development properly, you will want to order your questions by priority before proceeding. This is especially essential once you break down the questions into sub-questions and end up with dozens upon dozens of questions.

The best way to prioritise the questions is by uncertainty. An initial order for these three questions might then be:

  1. Can I make money from it?
  2. Can I get people to know about it?
  3. Can I build it?

Your own prioritisation may vary, but if you're technical, "Can I build it?" will probably be last on the list. Of course you can build it. If you couldn't, you would probably have discarded the idea before even getting to this stage.

Before trying to answer the questions, you first break them down into sub-questions (please note this breakdown is nowhere near exhaustive enough, it's just an example):

  1. Can I make money from it?
    1. How much will it cost me to serve the smallest users?
      1. Which cloud platform is best for this?
      2. How many instances will I need at a minimum to run the platform?
      3. How many users will I need just to break even?
    2. How much will I be able to charge per user?
    3. What proportion of paid vs free users will I have?
    4. How well will users convert from free to paid?
  2. Can I get people to know about it?
    1. What channels are there to get the message out?
    2. How much will each of these channels cost me?
      1. How competitive are the Ad-words for this?
    3. Do I have enough contacts to get the initial, core users so the service will be useful to real users?
  3. Can I build it?
    1. What are the hardest bits of technology I'll need to put together?
    2. Can the scope be cut down so that I have a chance of building a version 1 with extremely limited resources?
    3. Which features can be put off until later?

You should keep expanding this list until you can start to see what the burning uncertainties are. These will be unique to your startup idea and to your skills and available resources. Two people evaluating the same idea will probably come up with different key questions. Once you've got those key questions (the ones which make you think "Hmm, I really don't know this and it's really important."), shift those to the top.

Then, start working through the questions, one by one or even in parallel. Most of the time, the answer will not be found in code, but in good old-fashioned research, planning, and the dreaded Excel spreadsheets. You don't need to answer all these questions with 100% certainty, but you should be clearly aware of the limits of your answers, and when the answer is really critical, you should make an effort to answer it as fully as possible. You can't know everything, but you gotta know what you don't know and how much it can hurt you.

At some point, if the idea has answered enough questions, the next most important question will require you to build something - be it a paper prototype, a landing page, or something else. When it's the most important question, do it, and do just enough to answer the question. Later, if your idea is really good, you will probably, at some point, start to do the really expensive stuff: building a real application.

At that point, with so many critical questions having been answered, the likelihood that you build something that nobody uses or pays for should be low.

Of course, you may succeed by shooting from the hip and just going for it without a second thought, but more experienced entrepreneurs will usually look before they leap.

What should you do if an experienced mentor tells you it's a bad idea?  

Steve Blank:

And here’s the conundrum – given a wise mentor (or VC) with years of experience telling you it’s a bad idea – what should you as the founder do?

One thing I always tell founders at the beginning of all my talks is that they should always be aware of the background of the person giving them advice, because that will taint the advice. However, if the advisor does indeed have just the right background so that their advice is highly relevant, what to do?

The other part of what I tell founders is that ultimately, it's their company, their life, their decision. One of the things that makes startups hard is that you can't fall back and blame someone else. You made that call. You're the one who screwed up (if you did).

So what to do then? Steve Blank suggests asking yourself three questions:

  1. Are you passionate enough to still believe?
  2. Can you explain after why getting out of the building and hearing all the negative news you still want to persevere?
  3. Will it change the world enough to make it worth the trials, travails and pain in getting there?

... and then if the answers are positive, ignoring the experienced mentor and going for it anyway.

Asking yourself these questions may well be worthwhile, but in my opinion, if someone with experience and insight tells you that your startup is doomed, what you should do is much less dramatic: discuss why (in detail) with the advisor, to get a good map of how they expect your startup to fail. Then work hard to minimise those risks, which are probably very real.

Under no circumstances should you simply ignore the advice and "follow your passion". Most likely, the advisor's risk map is way better than yours. So use it to minimise risks.

As I often repeat, what you want is a plan that still has risks, but where the potential downside of those risks is minimised and the upside is maximised.

For example, if an advisor tells you "don't market this product to these large companies, they really won't give a shit about it," the right reaction is not to go and do it anyway "because you believe in your dream". Instead, figure out a way to test whether those large companies do give a shit, before spending lots of money on marketing to them.

Advice, good or bad, should never result in you relinquishing your responsibility to think for yourself.

Startup Therapy: Ten questions  

Not a new article, but one that bears reposting as we approach the new year, a traditional time of reflection.

See if you can find the time, over the next couple of weeks, to answer the following questions about your business:

  1. In one sentence, what does your product do and who buys it?
  2. In one sentence, why does someone buy your product?
  3. What one thing is most responsible for preventing sales?
  4. What one thing could you do to get more feedback from customers, potential customers, or sales you've lost?
  5. If you had zero revenue from now on, on what date would you run out of money?
  6. If someone handed you $100,000 today, how would you spend it to maximize future profits?
  7. If you were forced to hire someone today, how would you define her job such that she would contribute enough revenue to cover her expenses?
  8. Which of your business operations do you hate?
  9. What initiatives could be done half-assed without significant impact?
  10. If you could get one solid hour of advice from a guru you respect, what would you discuss and what would be the goal of the meeting?
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.

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.

Don't answer questions, tell a story  

Here's an interesting comparison of good and bad pitches in a specific context, that also applies to other context. By Andrew Peek:

My recommendation for any startup reading this, is to shift your mindset ever so slightly. Prepare like you would, but when you walk in that door, have a 4 or 5 minute story to tell, instead of 25 answers to 25 commonly asked questions. In fact, take this approach on every occasion where you get to pitch your business.

The next time someone asks you, “So what does your startup do?”, lay it on thick. Tell a story. Get them to empathize.

Software contracting legal clauses  

Many startup founders dabble in freelancing or running a services business, as a way to wean themselves off the corporate feeding tubes, before starting their first company. If you're thinking of doing that, or you're in the middle of it, reading this article will save you potentially large amounts of money and hassle.

It proposes a number of clauses that should be in any software creation contract - such as keeping the copyright to your work until paid, defining where lawsuits will be settled, or declaring who is responsible for testing the product and declaring it finished.

If you're based in the US, this article is directly useful to you. If you're in another country, you may have to find a similar article in another country (if you know of one, tweet it to me and I will add it here).

In my experience, spending £10-100 or equivalent on a standard contract template can be well worth the cost precisely because decent contract templates will include all those clauses.

Startup sales: #7: Lead generation depends on people

First, second, third, fourth, fifth, sixth parts. Now seventh part:

#7: Lead generation depends on people

The ideal (or rather, idealised) lead generation approach is one where you just have a process that magically produces a list of leads that you then approach, pitch, and close (or not). It's nice, impersonal and predictable, and is the given model for many mass-market B2B and B2C tools that are entirely web-based. Unfortunately, it largely doesn't match the reality of higher-price (product, service, or combination of both) B2B sales, at least not when it comes to small companies.

Instead, what I've observed actually happening is that different people have different preferred ways to generate leads. They have some ways they hate and some ways they love. As a new company, you need to make the most of the resources you have, and that means leveraging your people's abilities to generate leads, to the max.

Here are some examples of different people having vastly different ways to generate leads:

One person I know is extremely good at cold calling - insanely so. It might sound like an exaggeration, but I've observed him calling a company he's never dealt with before, and figuring out how to engage and build rapport simply from the way the other person said "Hello" when they picked up the phone. If you have someone like that on your team, obviously cold calling lists of companies becomes a viable lead generation approach (though it's still best to pre-qualify and triage those early leads).

Another is what I call a super-networker. She is simply able to work a room and meet almost everyone worth meeting. She then relentlessly follows up, builds relationships, and gets to know basically everybody. Her favourite and most effective lead generation method is obviously turning up at interesting events.

Myself, I find that my best leads have also come up in networking events, but much more indirectly. For me, it's best to be involved in an event in some capacity, which gets other people to come to me. Some of those then turn into very strong leads.

Every person has one more more lead generation approaches that work best for them. When you track statistics of "how many leads we got from X", bear in mind that when you're small, your salespeople's favourite lead generation techniques will vastly distort the numbers. Accept that and embrace it, because it gives you an edge over more systematised companies that try to shoehorn their sales force into standardised processes.

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.

Google Analytics Alternative