The Philosopher's Guide to Startups

[mattangriffel]

Does Growth Hacking = Lean Marketing?

In a conversation I had recently with Charlie O’Donnell, Partner at Brooklyn Bridge Ventures, the topic of growth hacking came up. “Explain this term to me,” Charlie said. “Everyone’s talking about growth hacking, but I’m not convinced it’s anything new.”

I explained that growth hacking is a set of frameworks, tactics and best practices designed to help startups think critically about the problem of user growth.

“That sounds like what a product manager does,” he said.

I told him that growth hacking is actually more of a philosophy of how marketing should be done at a startup, and as a result growth hacking incorporates a lot other disciplines like product management, direct marketing, brand marketing, and engineering.

“So growth hacking is basically lean marketing?” he asked.

I had to think for a minute, because I’d never heard it put that way. But I think he was right.

If you’re familiar with the concept of “lean” from lean manufacturing and most recently the lean startup movement pioneered by Eric Reis (The Lean Startup), Steve Blank (The Four Steps to the Epiphany) and others, then many of the concepts behind growth hacking should already be familiar to you.

The lean startup movement so far has been mostly focused on helping early-stage companies find product-market fit through customer development and quick iterations of the build-measure-learn feedback loop. At its core, the lean movement emphasizes validated learning, scientific experimentation, measuring progress, and getting valuable customer feedback. I’m a big fan.

Growth hacking is what happens when you take lean to the next level, beyond customer development and product-market fit. It’s what lean companies do once they’ve found product-market fit and now need to grow.

This helps us understand why Andrew Chen said that a growth hacker is a hybrid marketer and coder. At an early-stage company, the growth hacker is probably the first person who really thinks critically about user growth. They’re basically marketers, except that in order to operate lean at a very small company, they had better know enough about how to code to not be a liability to the company. Growth hackers have to be able to implement their own tracking code, put up their own landing pages, integrate with other APIs, and the like, otherwise they’re taking valuable time away from other developers.

Also, instead of minimum viable products, growth hackers develop minimum viable strategies. They need to quickly figure out minimum viable user acquisition strategies, minimum viable user activation strategies, minimum viable user retention strategies, and so on.

Growth hacking, lean marketing, agile marketing – whatever you want to call it – it exists. No one can deny it anymore. I’m excited to see where this goes :)

[mattangriffel]

Does Every Startup Need a Growth Hacker?

In my last post I explain what a growth hacker is. Now I will argue that every startup needs a growth hacker.

Most startups find themselves facing the same problem: they build a product that very few people end up using.

Let's say that your startup, Startuply has an idea for a new photo-sharing app. You assemble a team and start building it. At first it's awful, it's simply embarrassing. Your team encounters bugs and it takes much longer than you expected. Finally, six months later, you have a product you're happy releasing.

In the days leading up to your launch, you get more and more excited. You figure that your app has all the features that the mainstream photo-sharing apps are missing – the ability to edit photos on the fly, more filters, Foursquare-integration, and the ability to easily curate and share other people's photos. This is going to change everything.

When that day finally comes, you launch and… nothing happens.

Okay that's a slight understatement. You get a writeup in TechCrunch and several thousand users, but most of them stop using it after a few days. Nothing like the tremendous viral growth you were anticipating. What do you do?

Do you pivot? Do you keep releasing new features? Do you experiment with other marketing channels? Try to target a different demographic?

This is the problem most startups find themselves facing. It what Paul Graham calls the "Trough of Sorrow":

You know you need to change something, but the question is what? This is a dangerous situation. It's dangerous because the inclination most startups have is to keep developing and shipping new features. There's a feeling that something is missing and once that thing is added, your users really will start to come. 

Continuing to ship new features is probably the worst thing you can do at this point. Why? Because it just compounds what the real problem was in the first place, which is that you don't know what's wrong. Are people not interested in your product? Is your product good, but missing an important feature? Are people just not hearing about your product? Are you targeting the wrong audience?

Most startups that fail don't know the answer to any of these questions because they were in too much of a rush to release their product in the first place. A proper growth hacker looks at any decision that is being considered at a company and asks the following question: 

How will we know if it's working?

Of all the improvements in technology over the last few decades, I would argue that the one that has had the biggest business impact is the ability to collect data in real-time and make decisions based on that data in real-time.

As Tony Haile, CEO of Chartbeat, said at the Mashable Media Summit, people are really bad at making predictions more than a few weeks out. The ability to get data and respond to it quickly was what revolutionized the car industry when it came to lean manufacturing, and it's now revolutionizing are products are developed.

It baffles me that most companies waste so much time and money blindly releasing new products and features. They don't know how to measure the impact of what they're doing and how it affects customers. Most people want to jump right in because they assume that they're right and that measuring is a waste of time.

The problem is that there are at least a few hundred potential failure points along the way to building a successful product. Maybe users like the way your product looks, but they don't like the signup process, or the features listed on your homepage are unconvincing.

Let's say that, at best, the decisions you make at your startup (in both product and marketing) are right 75% of the time – trust me, that's incredibly optimistic and you're probably not even close. The problem is that with no feedback system in place, you don't know which 25% is wrong. (As the old advertising saying goes "I know that half of my advertising dollars are wasted… I just don't know which half.")

Growth hacking introduces a system for measuring the effect that startup business decisions have on product usage. 

Growth hacker can be a position at a startup, or it can be a mindset. I think that even if you don't want to hire a full-time growth hacker, you'll want to train someone at your startup on growth hacking methodologies. This could be your head of engineering or your CEO.

Your growth hacker helps ensure your company is actually making progress. At the end of the day, it's the only way to get out of the trough of sorrow besides pure luck.

[mattangriffel]

What is growth hacking?

I'm going to write a series of posts about Growth Hacking because I think it will be useful. I run a marketing agency for startups, and I identify myself as a growth hacker because during the course of my work I often implement various so-called "growth hacks". Due to a recent and well-read post by Andrew Chen, the term has become quite popular. But people often ask me where they can read more about growth hacking, and I've found there's no one resource for to send people to if they want to learn more about growth hacking. I hope these posts can serve as that resource.

First, what is growth hacking?

The best way to understand growth hacking and what growth hackers do is to first understand what is meant by the term hacker. A hacker is someone who is more concerned with achieving an objective than following a prescribed process. In other words, hackers care more about what needs to get done than how it should get done. As a result, hackers often come up with innovative ways to get things done.

For example, a hacker may be trying to get unauthorized access to a computer system. It doesn't really matter how he does it (and there often isn't one specifically prescribed method) so long as whatever he's doing gets him access. Because hackers are more concerned with what needs to get done than how it should get done, they tend to be pretty anti-authoritarian and also not do so well at bigger companies where they are expected to do things a certain way.

A growth hacker is a hacker whose objective is to grow the number of users for a specific product. While lots of people consider user growth to be a marketing function, this assumes that there's only one way to get users (namely, marketing). But this isn't true. In fact, more and more over the last few years we've seen new products grow from zero to millions of users with little to no marketing at all.

There are lots of non-marketing decisions that affect user growth. Building viral product features is the most obvious, but there are many others (I'll cover these in a future post). As a result, it doesn't make sense to place growth hacking within a particular department like marketing or engineering. Instead, it ends up being a cross-functional role.

The idea is that for every decision a company makes, a growth hacker should ask: "What will be the impact on growth?"

For example, when Facebook was still in its early stages they built a cross-functional growth team led by a growth hacker that touched many other departments, including Marketing, BizDev, Product, Finance and even HR. Among many other projects, the team was responsible for making Facebook available in every language through crowdsourcing, implementing a robust system for importing email contacts, and even building out a "Facebook Lite" which was eventually shut down (see Quora)

Over the last few years, truly innovative growth hackers have developed various frameworks and best-practices. Guys like Noah Kagan (AppSumo, Mint, Facebook), Mike Greenfield (Circle of Moms, LinkedIn), Dave McClure (500 Startups, PayPal) and many others have pioneered techniques focused on virality, email, search engine optimization & marketing. In my next post I'm going to write about the specific approach that growth hackers take and introduce something I call the growth hacker's funnel.

[mattangriffel]

The Remote Workforce

I'm seeing a tendency for people to start working remotely. A remote worker is someone with a laptop who can work sitting at home, at a cafe, or a coworking space. There are a number of reasons for this trend:

The realization on behalf of companies that employees no longer need to / shouldn't work 9-5 sitting at a desk. It's actually bad for productivity. As are the constant interruptions. People end up happier and more productive.

Technology that enables the same level of personal communication needed over the internet. This includes the mainstream adoption of laptop computers and technology that enables video teleconferencing as well as project management systems like Git or Bootcamp.

Valuable people with skills that companies could never get access to previously, all over the world.

Reduced overhead costs associated with physically housing an employee.

A consequence of this is that people are starting to work more than one job. When you're expected to sit at a desk at a company 100% of the time even though you're only productive 30% of the time, it's hard to find another way to fill that leftover 70%. But when you're working remotely, you can take on 2-3 projects at a time.

Sometimes a dream about a day when companies are no longer concrete groups of individuals as much as outsourced roles. A CEO could divide his time and be CEO of multiple companies, as with CFO, Lead Developer, VP of Marketing, etc. In a world like this, coordination and project management becomes one of the most valuable skills.

[mattangriffel]

Why it doesn't matter if your product is better

It doesn't matter that your startup's product is better than anything else out there. There, I said it.

Let's try a little thought experiment: What if I told you there was a better search engine than Google? Or a better email client than Gmail? Or a better social network than Facebook? Would you switch? It's unlikely.

You wouldn't immediately switch to a better product because, at the end of the day, how good the product is isn't the only thing you care about.

So why is it that I talk to so many startups whose entire strategy is to build a better dating site or a better way to share pictures by location?

History is littered with inferior products that won out over superior ones. It happens all the time. In fact, that's usually what happens – for any product you can think of, there's a better one somewhere out there.

In other words, it doesn't matter that your product is better than anything else out there. Instead, there are a few key things your product has to do to attract and retain users.

Your product has to make people's lives EASIER.

That means: quicker, more intuitive, and better aligned with what people want to do than the solutions that are currently available to them.

Most people don't care whether or not your product has more features. If your selling point is "look at all the things you can do with out software," what your audience hears is "look at all the new things you have to learn how to do."

Adding more features to your product is usually a bad idea because it's harder for people to figure out how to do exactly what they want to do. When Google first came out, part of the reason it became the most popular search engine was because when you told someone about it, you didn't have to explain to them how to use it. It was STUPID SIMPLE.

Your product can't JUST be better. It has to be MUCH better.

People aren't going to automatically switch to using your product just because it's better. There's actually a very rational reason for this: if you had to switch to a different product every time a better one came out, you'd spend all your time learning how to use new products and never actually using them.

In economics, this concept is known as "switching cost." Switching costs can be actual costs – like you being forced to pay a fee to your telephone carrier when you cancel a contract – or mental – like you having to learn how to use a new piece of software. Your product has to be so much better than what people are currently using that it makes up for the cost of switching.

The QWERTY keyboard is a classic example of this. The QWERTY keyboard layout (the way the keys on your computer are mapped out) was designed back in the day when typewriter ribbons would jam if you typed too fast. QWERTY was literally designed to make it harder for you to type, like a built-in speed limit. Of course, this hasn't mattered for a while, since everything is electronic and there are no more parts to jam.

Much more efficient keyboard layouts have been invented – the Dvorak layout, for example (picture below), has been proven to be 59% more efficient – but this doesn't matter because the cost of learning how to use a different kind of keyboard, as well as the fact that QWERTY is such a market leader, make the switching costs way too high.

It also has to be IMMEDIATELY obvious that your product is much better.

This is an incredibly important point that most people who build products don't realize. Even if your product is much better than an alternative, you shouldn't expect that first-time users will realize that. If it takes someone two hours of playing around with your software to realize how much better it is, you've probably already lost him.

Users usually size up the value of a product in five minutes or less and they hate to read documentation. A friend of mine has a saying: "Ostensibly, every user manual says the same thing: this product was poorly designed."

This is what happened when people tried Google+. Undoubtedly, Google+ had some big advantages over Facebook when it was released. But the big advantages weren't really immediately obvious. Most people played around with it for five minutes and then thought "Hey, this is a lot like Facebook." So they went back to using Facebook.

Sure, Google+ let you put people into groups and gave you access to any number of features that didn't already exist on Facebook at the time, but it took more than five minutes to set up and it didn't feel different enough from Facebook, most people bailed.

Most people will spend less than a minute on your product's site before they decide whether or not to click the back button. That's the amount of time you have to convince someone to try out your product.

If you can do that, then you've bought yourself an extra five minutes of someone's attention, no more. If they're still interested after five minutes, then they'll stick around for an extra 20 minutes, and so on.

So how do you keep them interested? 

Think of a user's first product-experience as a first date.

Would you go into a first date and immediately tell someone everything about yourself? "My name is Mattan and I used to be a yoga instructor and I know how to juggle and blah blah blah." I really hope not.

You have to create interest and build up some intrigue as well. To have to find out what they care about and then show them why they should want you in their life. Otherwise, good luck getting that second date.

[mattangriffel]

A wonderful person, Chanelle Henry, sent me visual notes of a class I just taught on How to Teach Yourself to Code. Check out Chanelle's other beautiful work at CHD Collective.

[mattangriffel]

How The JOBS Act will hurt the startup industry

(a version of this post ran on The Next Web)

Today, Obama is set to sign into law the Jumpstart Our Business Startups (JOBS) Act. In this post I’m going to argue that the passing of the JOBS Act is really bad for the health of the startup industry. Specifically, the JOBS Act is likely to lead to a startup speculative bubble and a subsequent crash (like the dot-com bubble of the late 90s) .

What worries me most about the JOBS Act is not how it loosens restrictions put into place after the last dot-com bubble, or that it lets banks essentially advertise companies before taking them public (although those things are worrisome on their own), but that it legalizes something known as “crowdfunding.”

Crowdfunding means individuals can invest directly into startups at very early stages (like Kickstarter except you actually get a piece of the company). Your average person – meaning a “non-accredited investor” – can invest up to $10,000 annually in return for equity in startups.

Startups are already overvalued and this is going to make it worse. Overvaluation happens when investors start to overlook traditional metrics (such as P/E ratio) in favor of new metrics based more on potential future revenue (like price per user or price per page-view). Early-stage valuations have doubled in the last two years. Companies like Tumblr, Instragram, Pinterest, and even Twitter are being given insanely high valuations based not on revenue but on the number of users they have. This doesn’t matter though, because my argument holds regardless of whether startups are currently overvalued.

At the end of the day, the legalization of crowdfunding means it’s easier for startups to raise money, and so two things happen: 1) startups that weren’t able to raise money before will now be able to raise money, 2) startups that would have been able to raise money before will now be able to raise money at higher valuations.

Let’s consider first the fact that some of the startups that weren’t able to raise money before will now be able to raise money. At this very second, if you have a solid team and/or a good idea, it’s already pretty easy to raise money.

Crowdfunding helps out people who want to raise money to start companies but don’t have access to angel investors or VCs. I’m willing to accept that maybe a few of them have great ideas and are just unfortunately unable to get in front of people with money, but the majority of people that weren’t able to raise money before were turned down because they had a bad idea or a bad team.

So crowdfunding will let regular people (who are less likely to be able to asses the risk of a potential investment) invest in companies that angels and VCs deemed to be too risky. That’s not good for the health of the startup industry.

And companies that would have been able to raise money before will now be able to raise at much higher valuations. This follows from basic economics: more potential investors and more money equals more demand, which leads to higher prices for startups. That’s not good for the health of the startup industry.

Let’s take a look at another consequence: there will be a lack of tech talent to back up the creation of all these new startups. Developers are already in extremely high demand. Each new startup that gets funded will need at least a small team of developers. There simply isn’t enough tech talent out there to sustain twice the number of startups as there currently are.

As demand for developers increases, developer salaries will shoot through the roof. Remember, it will be easier than ever for startups to raise money, so they’ll spend a lot more of it on tech talent. I can see salaries for lead developers climbing upwards of $300k a year (in many cases they’re already getting $150k-$200k). What’s more, given an overall dearth of talent, in some cases unqualified developers will be put into positions of lead developer or CTO when they shouldn’t be. That’s not good for the health of the startup industry.

More startups means it will become harder for good startups to stand out. That means even with a good product, startups will have to start spending money on marketing and advertising to even get noticed. That’s not good for the health of the startup industry.

Finally, what happens to all these startups one year after they raise money? At that point they’ll have burned through their series A and will need to raise follow-up money, but many of them won’t be able to. Crowdfunding might sustain early-stage investments, but since the typical Series B investment is around $4 million (and crowdfunding legally caps out at $1 million annually), these startups will have look for financing from traditional VCs. A lot of them won’t be able to get it. They’re either have to raise down-rounds, or dissolve the companies.

That’s the part that worries me. As far as bubbles go, that’s what you call a “pop,” and that’s definitely not good for the health of the startup industry.

[mattangriffel]

I turned my series of blog posts on How to Teach Yourself to Code into a class and threw it up on Slideshare.

80,000 views so far! That's more than I had ever anticipated

[mattangriffel]

On Learning to Code, pt. 3: Resources to Teach You Rails in a Month

(a version of this post ran on General Assembly)

In my last two posts, I covered why you should learn how to code if you're a non-technical entrepreneur and why you should start off learning learning Ruby and Ruby on Rails. Now, on to the good stuff – I'm going to write about the actual steps I took to learn how to code a complete application in Rails in under a month.

Since I find the process of memorizing by looking at the same material over and over again extremely tedious, I've developed my own method, which involves finding a handful of introductory classes online and speeding through them really quickly. When I was in college, I used to download podcasts of the same courses I was taking but at different universities, like Berkeley or Stanford. Then I'd listen to the podcasts while I was on the subway or walking around. It turned out that my approach eliminated hours of studying I would have had to do otherwise, and teachers love it when you're able to bring in a unique perspective that wasn't covered in class.

What happens is that sometimes the way a concept is taught really resonates with you, and sometimes it doesn't. You'd be surprised at how often I've been confused by something when it's explained one way, but when I hear a second person explain it, it just clicks. Put another way: if you were in a room full of smart people, would you ask the same person to explain something to you over and over again, or would you ask a bunch of people? Another benefit, besides the fact that it’s less tedious, is that the stress of having to remember everything the first time disappears. If you miss some specifics when you’re first exposed to them, that's okay! In fact, that's sort of the point. The first time you learn something, you should get a general sense of how all the pieces fit together and what the goal is. Then go back and relearn the specifics with new knowledge of how they fit into the picture as a whole--this way you’ll actually be able to store more information overall.

So what I recommend is that you speed through as many of the introductory tutorials as possible. Just plow through them. Here’s the path I took:

Step 1: Ruby on Rails 3 Essential Training by Kevin Skoglund  Technically you have to pay for Lynda.com, but they do offer a free 7-day trial period. I powered through this course in about a week. By the end, you'll have built out a simple content management system. It also does a pretty good job of walking you through how to install everything you need to start programming. It doesn't cover all the details, and you probably won't be able to build you own application by the end of this first week, but that's not the point anyway.

Step 2: Ruby on Rails 3 Tutorial by Michael Hartl This one takes longer and is more in depth than the Lynda.com tutorial, but it's probably one of the best and most commonly used resource out there for learning Ruby on Rails. And by the time you've gone through the Lynda.com tutorial, this stuff should be much easier to grasp. This whole tutorial took me about two weeks to get through. By the time you're done with it, you'll be able to build out your own basic application.

Step 3: Web Applications by John Ousterhout at Stanford University Just watch the sections on Ruby, Rails, Active Record, Cookies and Sessions, and Forms. I love this guy and these videos should start to give you a broader understanding of where Ruby on Rails fits into the larger computer science landscape. The video quality is decent, but not great.

At this point you'll be able to build out your own basic applications, but there may be specific features you don't yet know how to implement. Which brings us to...

Step 4: Railscasts by Ryan Bates Here you'll find tons of short videos about how to do really specific things in Rails. If you've got some feature you're trying to build out in your app, chances are Ryan covers it here.

The tricky thing is that lots of times you know what feature you want to build, you just don't know what it's called, so you don't know what to search for to find more information. I haven't found a better way to do this than trial and error, except for asking experts. That is, if you say to an expert: I want the user to be able to do x and get y, a pro can often say, oh what you're looking for is a Cron job or something like that.

Bonus Resources: A few other fun ways to learn Ruby itself that I've tried: Learn Ruby The Hard Way, RubyMonk, Ruby Warrior, and Ruby Koans. They all seem pretty good, but they cover more basic Ruby.

Resources for Troubleshooting: You’ll often run into problems or new challenges you need to figure out. You can find answers here:

Stack Overflow This is where people post specific problems and questions they have, and you can find verified answers to questions. Chances are if you're running into some problem, someone else has already run into the same problem, posted it here and gotten the answer.

Google (did I really need to link to that?) The world's source for answers to everything. You'd be surprised how often I've run into a problem, copied and pasted a snippet of the error code into Google and found the answer.

Joining the Ruby Community: One bonus attribute of Ruby on Rails is that it happens to be very popular at the moment, and there’s a large community of people supporting it. One of the best ways to learn is to go to Rails meetups and ask someone who knows more than you. If you're in NYC, check out the following meetups:

NYC.rb NYC on Rails New York Ruby Meetup Ruby Nuby

I'd also suggest once you start developing a working knowledge of programming languages that you go attend some hackathons and find teams to work with. In NYC, you'll find a lot of hackathons happening at places like General Assembly or Pivotal Labs. To hear about them, sign up for the following mail lists:

General Assembly This Week in NYC Innovation

I'm also going to be teaching a class called "So You Want to Learn to Code?" at General Assembly in February, so stay tuned...

Thanks to Anna Lindow, Jeremy Welch, Rob Spectre, Tim Olson and Kevin Shiiba for reading drafts of this.

[mattangriffel]

On Learning to Code, pt. 2: Choosing a Programming Language

(a version of this post ran on General Assembly)

In my last post I wrote about why, if you're starting your own company without a technical co-founder, it makes a lot of sense to start learning how to code on your own.

Not knowing much about coding makes it especially scary to jump right in. You've probably heard just enough about all the different programming languages–C++, PHP, Java, Python, Ruby, etc.–to have no idea where to start.

The truth is, most of these languages can do the same thing. They're just different ways of doing it. Yes, there are some exceptions, but you don't really need to know about those when you're starting out. So which language should you learn?

If your goal is to build a prototype for an idea you have, you should start off by learning a framework called Ruby on Rails (or 'Rails' for short). Rails is called a framework because it's built on top of another programming language (Ruby–hence the name "Ruby on Rails"). There are a few good reasons to start off with Rails:

The point of the Rails framework is to make it really easy for you to build web applications–basically, websites–very quickly.

There are other web application frameworks out there (like Django), but Rails is the easiest to dive into right now because there are a ton of resources available to help you out (which I'll cover in the next post) and a huge community for you to tap into.

I personally think Rails does the best job hiding all the stuff that you don't really need to know about at first. There's a pretty famous video in which the creator of Rails demonstrates how to build a weblog platform in 15 minutes.

A lot of developers will argue that the right way to learn programming is to start with the fundamentals and work your way up. They'll suggest you start with a language like C++ or Java and then build up to the more abstract languages. I understand the temptation to say this, because it mirrors the way we learned things in school and it also happens to be how most experienced programmers learned how to code, but I think it's the wrong way to learn coding.

People don't want to spend months learning "if… then" loops so that they can finally build something really stable but really simplistic, like a text-based game. If you're like me, you generally give up on learning a new skill if you don't see fast results. With Rails, fast is the name of the game.

A friend of mine once told me a story that finally convinced me to start learning how to code. He recounted a time he and a friend were working at a parking garage a few summers back, and they came up with the idea to build a site where people could submit Four Loko stories: short anecdotes about Four Loko-induced debauchery. He didn't know where to start, but he had the whole summer ahead of him, so he started learning Rails. Within a few weeks he had a site up and running. And here's the amazing part: without active marketing efforts, the site started generating a lot of traffic on its own. So he threw up a few banner ads. To this day, he's still getting thousands of page views–and checks in the mail each week.

The ability to get quick and positive feedback on your projects is crucial to building momentum. So: learn the minimum skill set you need to get feedback fast; then go back and fill in the missing pieces. 

In my next post I'm going to cover how I learned Rails in under a month and tell you all the tips I wish I had known, so that you can get started even faster.

Thanks to Jeremy Welch, Rob Spectre, Rohit Dave, Tim Olson and Kevin Shiiba for reading drafts of this.

[mattangriffel]

On Learning to Code, pt 1.

(a version of this post ran on General Assembly)

I want to write about a topic that I think will benefit a lot of people: learning how to code. When I first quit my job to start my own company, all I had was an idea. The goal at that point was to find someone with a technical background to actually execute my idea. I suspect that many of you are in similar situations. There's something you should know: it's never going to happen.

Demand for developers has skyrocketed to unprecedented levels. Think about it. Anyone with any aspirations in the tech scene is starting their own company right now. Each of those startups needs its own lead developer (not to mention that companies like Facebook and Google are sucking up thousands of talented developers).

Please don't want to wait around trying to find that perfect technical co-founder. If that's your goal, then you're bound to fail as an entrepreneur. Entrepreneurs don't look for people who are able to execute for them. They improvise and make things happen in spite of being under-equipped. You're not expected to become a master hacker (or even an adequate one at that), but you had better learn how to code well enough to put together the first version of your product yourself.

As an entrepreneur, learning how to code is useful even if you're not actually going to be coding full-time. One day you will be expected to manage a team of developers. At the very least, you will need to be able to interact with developers in order to pitch them on joining your startup. Where do you find developers? What do you talk to them about? How do you get them excited about your project? It's much easier to do these things once you've learned how to code.

That leads to me what I feel is the most important reason to learn how to code: more and more, the things we interact with in the world around us qualifies as technology. For most people, technology is the first thing we interact with in the morning when we wake up and the last thing we do before we go to sleep. For example, 83% of young people sleep with their cell phones next to them. 

Very quickly, society is becoming divided into two groups: those that understand how to code and therefore manipulate the very structure of the world around them, and those that don't – those whose lives are being designed and directed by those that do know how to code.

So I think it makes a lot of sense to start learning how to code. As an added benefit, it's easier than ever. In my next post, I'm going to talk about where to start.

Thanks to Paul Ratajczyk, Rob Spectre, and Kevin Shiiba for reading drafts of this.

[mattangriffel]

This interview with David Lifson, co-founder and CEO of Postling, was conducted and condensed by me, Mattan Griffel. It's the first in a series of interviews I'm doing called the Founder's Funding Series, in an effort to shed some light on the process of raising money for your startup. 

I first met David when a mutual friend introduced us and I later read about how he raised $200k in 6 days for Postling. So I reached out to interview David about what that was like, and he happily obliged.

Q:  Do you remember the first time you decided to start a company? That wasn't Postling, right?

A: Yeah it was a company called Waffl, which was Esty for Bed & Breakfasts. In the last couple weeks of my time at Etsy, I decided to go to Ithica for a weekend with my girlfriend and stay at a bed & breakfast. Long story short: I couldn't book a room. They don’t do online reservations at these places because they're mostly run by older people. So I thought, "Damn! Someone should build an Etsy but for Bed & Breakfasts." But I put that idea aside and when I quit Etsy I started looking around for a regular job. That was November 2008 and it was like the death of the stock market no one was hiring.

Then a friend from college who I hadn’t spoken to in 3 years saw on Facebook that I was looking for a job. He reached out and asked, "Do you want to start a company?" So we met up for dinner, I pitched him three ideas, and he liked the bed & breakfast one the best. He asked, "How much do you need to get it going?” I told him, “I don’t know, probably $5,000 a month.” He said okay, wrote me a check and gave it to me right there.

So for three months I would meet him and get my $5,000 check. But at the end of the third month he said, “Dave, I’m really disappointed. You don’t have a website yet. You don’t have any customers. You haven’t even picked a name yet. What the hell are you doing? This is my last check.” And then he cut us off. That was a really great wake up call for us because at the time we hadn't understood the difference between work and progress. We had plans, lots of plans. We had specs, we had database schemas, but we didn’t have anything that real customers would use. 

Q: So what did you learn from that experience about the process of developing an idea?

A: Well we abandoned Waffl three months after launching it and switched to Posting. And the reason was customer acquisition. We hadn't through how the hell we were going to get in front of people. If we had built a model I think it would have been obvious to us before we had even written a line of code. It’s like, “Well to make this work we’re going to need to charge this much money a month and we need to acquire this many people a month. How the hell we are going to do that? There’s no way? Okay next idea.”

We got the idea of Postling from from the bed & breakfast people, actually. They're the ones who told us, “We’re overwhelmed by all this social media stuff. Put it all in place and we’ll pay for that.” And thought, “Okay, you’ll pay for something? We’ll build it.” And so again it was six weeks from idea to launch: we launched August 1st 2009.

Q: What kind of entrepreneurship lessons what did you learn from that experience?

A: Don’t spend a lot of time planning. Once reality hits, it becomes a very different thing. However you should build a business model. Don’t worry much about the business plan because there are so many assumptions there it’s kind of waste of time, but building a spreadsheet is really important and something we didn’t do. What the spreadsheet does is tell you what numbers need to happen such that you get a business that’s worth your time. Like... it only works if we are able to charge more than $20 a month... or it only works if we are able to acquire more than a 1,000 people a month. Whatever those assumptions are, you need to find out what your limits are so you can ascertain if it’s worthwhile.

Q: What were some lessons you learned from the process of startup funding?

A: We already had all the documents figured out so we knew that we were going to raise on equity, not convertible debt. We knew that we were going to raise at $1.4 million pre, and that we were raising $350,000. We knew that we were going to give ourselves 60 days to close the round. Because we had all the things figured out, all of the usual negotiations and wishy-washyness was off the table. It became very black and white: Do you want to invest or not? And the reason why I was so non-negotiable is that we already had the first $130,000 committed on those terms.

Q: What kind of advice would you give to an entrepreneur in process of funding a company?

A: Don’t ask for money. Investors aren’t interested in funding you because you’re going to run out of money if they don’t. You have to put yourself in the mindset of the investor: why do they invest us? Most angel investors do it because they have a lot of money and they set aside a certain amount to invest in startups because it’s fun. It’s an asset class just like stocks, or mutual funds, or treasury bonds. And so since investing is a hobby for them, it’s very emotional. They want to be a part of an adventure. So what you need to do is convey to them that you’re doing something amazing and you’d like them to be a part of the process. And that the reason why you are choosing them is specific. You want them because they have certain experience or certain connections, whatever it is so they can feel like they’re actually helping and that they're not just dumb money. You really have to project a lot confidence and strength and say,"Our numbers are great. We don’t need you. But if you want to be part of this, we can make some room." You’re trying to create scarcity out of nothing and it’s really a hard dance. These people are smart. They made the money because they are smart, and they have a really good bullshit sensors. But there is a way to do it.

Often that means you have to start raising money before you need the money, because once you need it everyone can smell that. And then they’re thinking, “Why should I give you money if it’s likely that you guys are not going to raise enough and therefore go bankrupt anyway?”

Q: What advice would you give people in the earlier stages, maybe those who are at a job thinking of starting their own company? 

A: When people think about starting their own companies they spend a lot of time creating a business plan and thinking about all the mechanics of what they will do once they quit. I think what they fail to do is properly validate whether or not their vision of the future is one that’s both profitable and possible. Because how you get there is probably going to be different than what you thought. The point is: is the promised land worth getting to? And do you have the means, the people, and the talent to figure out how to get to the promised land? If so, how you get there actually doesn’t really matter so much.

That’s what I would think about: does your vision of the future work? And make sense? And excite you? And be the thing that you want to give up the next three to five years of your life to do? And do you have the team and the right skills to do that? If so, then don’t really worry so much about how you’re going to do that. Because you’re going to be wrong. Reality will hit your business plan and you’ll realize, “Oh man, I was totally wrong about that.” But if you have the right faith in your vision then you can get through that. Too often people think about tactics and that’s the part that actually changes the most.

Also when people try to work full-time and do their start-up on the side, it almost never works. Part of it is psychological. You’re not making yourself vulnerable enough to really make the sacrifices that are necessary. It feels like you’re making sacrifices. Your life sucks because you’re working two jobs. But in the end I just feel like the necessary amount of focus and determination and passion really only comes out if you’re doing this full-time. The last thing is that investors will almost never fund you if you still have a job. Because they’re thinking, “If you don’t believe in this enough to quit your job, why should I give you my money?”

[mattangriffel]

On Quitting

This post is now here: http://learn.onemonth.com/becoming-an-entrepreneur-on-quitting