The Philosopher's Guide to Startups

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 :)

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.

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.

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:

1. 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.
2. 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.
3. Valuable people with skills that companies could never get access to previously, all over the world.
4. Reduced overhead costs associated with physically housing an employee.

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.

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.

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.

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

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.

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:

1. The point of the Rails framework is to make it really easy for you to build web applications–basically, websites–very quickly.
2. 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.
3. 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.