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.
If you read this far, you should follow my RSS feed here.
To raise or not to raise ✶
Joe Stump, founder of SimpleGeo, has written a pretty solid article examining whether people should raise capital or not. It's a balanced view that looks at both angles instead of dismissing or praising fund-raising outright, and mostly matches with my views on raising investment:
I look at capital, whether it comes from an angel, a VC, or a traditional bank loan, as an accelerant. It’s like gas. Sometimes your fire is burning nice and bright. You’re warm and have plenty of heat so why pour more gas on the fire? Sometimes, however, you’d like to start another fire, or maybe you’d like to burn down a house, or, possibly, you’d like your little glowing embers to be a fire more quickly than is otherwise naturally possible. These are all great reasons to reach for the can of gas.
Joe lists a number of good reasons to raise or not to raise. Reasons to raise:
- Your business is capital-intensive.
- You're at an inflection point and the capital will help you grow 10x faster.
- You want to get some money out. (I find this one dubious - just pay yourself a better salary!)
- You can't afford to keep working on your startup. (I disagree with this one, that's using investment as a cushion)
- It'll give you access to a lucrative partnership.
Reasons not to raise:
- It's hugely distracting.
- If you raise too much, you might get hurt in later rounds.
- If you raise at too high a valuation, you'll be taking early exit options off the table.
- You give up control of your company.
- Even after raising, investors are a huge distraction.
- You may not get the attention you want or need from your investors.
Finally, Joe offers some tips about do's and don'ts of fund-raising, but you should really just go read the article to find them out.
If you read this far, you should get more similar articles by email.
How to interview developers ✶
This is the method I've been applying for some time now (not at a large scale, but quite reliably):
So what should a developer job interview look like then? Simple: eliminate the exam part of the interview altogether. Instead, ask a few open-ended questions that invite your candidates to elaborate about their programming work.
- What's the last project you worked on at your former employer?
- Tell me about some of your favorite projects.
- What projects are you working on in your spare time?
- What online hacker communities do you participate in?
- Tell me about some (programming/technical) issues that you feel passionately about.
Basically, have a relaxed, friendly chat, and tease out whether they're a bright, passionate geek, or not.
Worth noting that this method is, in my opinion, only applicable by people who are themselves developers. If you're completely non-technical, you'll struggle to tell apart a good bullshitter from a geek. Whereas as a geek, it's very easy to do. Any chat about past side projects will involve numerous statements that only a geek can get consistently right - and one slip-up is enough to discredit someone, in this game (for example, "Yeah, I built this 3D engine in C++, it was pretty cool. It ran in the browser." would need some very good follow-up to be convincing, and a flake would not be able to come up with it).
If you read this far, you should follow my RSS feed here.
Reckless risk-taking ✶
Philip Kaplan proposes that instead of worrying about low-probability risks, an entrepreneur should just power on ahead and sign whatever the client asks:
This lesson in total disregard for risk served me well. They say entrepreneurs are risk takers. I think of myself as too lazy and irresponsible to fully understand the risk.
It works for me.
I’m not sure what the lesson is here.
I think this falls squarely in the "very dangerous, easily misunderstood lesson" category.
If you met someone who crossed the road with his eyes closed his whole life, and said "no need to worry about crossing the road, just close your eyes and go right ahead - it's worked for me so far" you wouldn't take that advice seriously.
Now, the reality of entrepreneurship is that standing on the side of the road worrying about the cars costs more than just crossing, and if a car does hit you it won't necessarily cost you your life. So, it makes sense to just decide and go with it rather than worry about things too long.
However, that doesn't mean that you should take risks on casually and naively. The best entrepreneurs are risk-takers in the sense that they will take measured, calculated, mitigated risks for the chance of good rewards. They are not risk-seekers, they will not seek out unnecessary risks, nor will they naively accept every risk that comes their way.
In the examples he cites, Philip had an experienced entrepreneur looking over his shoulder, and also used his own gut feeling to help him make the decisions. What's not mentioned in this anecdotal article is all the deals he rejected before they even got to the contract stage, because he had a bad feeling about them.
As a smart founder, you need a bias towards making decisions, and you need to be willing to take calculated risks (ideally risks with a small, limited downside and a large, unlimited upside). But you should still think through what risks you are taking on, and do whatever you reasonably can to minimise those risks.
In other words, don't wait until you have a live GPS map of all the traffic before crossing, but do open your eyes and look both ways.
If you read this far, you should follow my RSS feed here.
If you build it, they won't come ✶
Tom Buck:
If you build an application first, chances are you’ll get pretty disappointed when the initial burst of announcement traffic dies down… and you’re left with close to zero sales. Sure, there are success stories out there, where an app brought in megabucks from it’s very first mention, but – and I’m Sorry to say it – unless your lottery numbers come up on a regular basis, this is not going to happen to you.
Indeed. It's a paradox and a fallacy: the inexperienced salesperson thinks it is much harder to sell something that doesn't exist, than something that does. Surely, if it exists, people are more likely to buy it, right?
Actually, selling something that exists only in your mind is far easier, because once you've sold something, so long as it's realistic and achievable, you can very likely create the thing that you sold.
On the other hand, when something exists already, it needs to match your customer's specific requirements in order to appeal to them. This is certainly possible - and all successful products do it - but it mostly arises when the work of building the product was preceded by an effort to discover the market.
And the best way to do that is to try and sell the product before you build it.
If you read this far, you should get more similar articles by email.
Venture capital basics ✶
This is a good, relatively brief overview of the basics of looking for money from VCs.
If you're not familiar with any of the concepts in it, it's worth a read. Covered:
- What VCs are looking for
- The difference between VCs and angels
- Asking for the right amount
- Planning on future rounds of investment
- Understanding pre-money, post-money and % ownership
- Negotiating
- Comps
- % ownership
- Exit strategy (with example)
- Understanding how a VC fund works
- VC maths
- The fallacy of taking other people's money
The right funding strategy ✶
Another good article by Roger Ehrenberg, this one about picking the right investment strategy for your startup.
In summary:
- If you can generate cash flow early, bootstrap, and only raise capital when you absolutely need it.
- If you need a bit of capital (up to $500k or so) to prove the concept, go to angels, but if you expect high exploitation costs (e.g. you'll need lots of sales people), get VCs involved in the round too.
- If you need a lot of capital up-front, go to VCs straight away to have the relationships in place.
Seems obvious, but many people go straight from "I want to build a startup" to "I need some funding". Don't be one of those.
A couple of key points to add:
- The less experience you have of running businesses and/or startups, the more you should aim towards the bootstrapping end of the scale. Very few people in the world can walk out of a VC office with $10m in initial funding based on zero business experience. So if this is your first business, build something you can monetise soon.
- Be careful about the "involve VC firms early" thing. If they pass on you, it may be difficult to get other VCs interested.
If you read this far, you should follow my RSS feed here.
Learn from your competitors ✶
Mark Suster has posted another article (or rather, a second part to yesterday's article, discussing how to treat your competition.
The very sensible suggestion is to avoid the easy macho assumption that your competitors are all stupid, and instead go out and meet them and have friendly meetings discussing various problems your industry is facing. After all, you're all trying to solve the same problems, and have a lot to learn from each other.
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:
- Execution is more important than the idea;
- Someone else has the exact same idea anyway;
- Completely unique ideas generally don't make it;
- The most likely cause of failure is your incompetence, not the competition;
- You desperately need real feedback;
- 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.
If you read this far, you should follow my RSS feed here.
