Breaking into Growth Hacking

First, Why It’s Hard

Many web career paths involve starting as an amateur and growing into a professional: the bar to becoming a Developer can be as low as reading a tutorial and writing your first “hello world” script, and the bar to becoming a Designer can be as low as viewing an inspiration gallery and posting your first illustration on Dribbble.

Both will probably result in terrible, painfully amateurish output, but it will be a start – a start that a Designer or Developer can build on and, if they get good enough, eventually charge for.

Not so much for Growth Hackers.

While it takes very little to learn growth hacker tactics and methodologies on your own, trying to actually put them into practice on your own can pose significant challenges. The heart of growth hacking involves conducting experiments & measuring results, and you simply can’t do that from scratch in your spare time, like a designer sketching in a notebook or a developer forking a git repo.

Your Canvas Is Traffic, and Traffic Ain’t Cheap

While the tools of the trade for designers and developers are usually either inexpensive or completely free, you can’t conduct experiments without something very expensive: website traffic. In order to achieve statistical significance in anything resembling a reasonable timeframe, you need a minimum level of monthly visitors to work with (running 3-month-long A/B tests isn’t a sustainable career development strategy).

A high-traffic site isn’t something that can be created out of thin air, and it raises the barrier to entry far beyond weekend side-projects. It even excludes the “mom & pop” type sites that constitute a lot of the first paying gigs for designers & developers who are just starting to cut their teeth. Photoshop and a customer with a $1000 budget might get you your first job as a web designer, but the stakes for growth hacking are much, much higher.

Mo’ Traffic, Mo’ Problems

Of course, the sites that do have enough traffic are usually, by their very nature, well-established. This often also means that they have entrenched internal stakeholders with a nontrivial amount of influence (they’re who got their site to where it is, after all). If those incumbents don’t already have a growth hacker mindset, it can be very, very difficult for an outsider to inspire such a culture change.

It also greatly raises the risks for both parties – the aforementioned designer and their client can probably afford some rookie mistakes on that $1000 website, but an up-and-coming growth hacker cannot afford to make nearly as many when a six-digit ROI is on the line. This is a very difficult profession to learn on the fly without the safety net of a forgiving team behind you, which is unlikely to happen if you’re an outside contractor. Speaking of which…

Outsourcing Hands vs. Heads

Many designers and developers get their start with one-off paid gigs, with lots of companies happy to farm out production work like comps for a redesign or to bring in another pair of hands for an engineering effort. It is much less common, however, for a company to contract out business results (a growth hacker’s stock in trade).

How many companies would sooner delegate the design of their entire brand identity or offshore the development of their entire web app before they’d allow an outsider to even look at their sales funnel conversion rates?

Outside of perhaps the SEO world, I don’t know of many entry-level web gigs based around performance instead of production. There is simply not much of a precedent of companies bringing in an individual, opening up their kimono regarding their most sensitive business & customer data, and allowing said person to conduct an experiment that requires cross-departmental effort to pull off. (Individuals like Lincoln Murphy and agencies like Conversion Rate Experts are the exceptions here, afaik)

So what can you do to get started? I see three main tracks:

3 Tracks for Breaking into Growth Hacking


Become an established player at a company that has enough traffic to hack on. Gain experience on their dime.


  • If employer & employee see eye-to-eye, this is by far the most straightforward track.
  • If you don’t have a growth hacker background, you can aim to be hired as something close (a Product or Marketing role) and consistently stump for adopting GH practices.
  • I also see a lot of companies hiring people on their potential to be a growth hacker, which can be a great approach for both parties.


  • If you’re hired on for something non-growth-hacky, don’t underestimate the time involved in doing your “real” job – this approach may wind up being a “long play” in gaining GH-specific experience.
  • If your ultimate motive is to gain transferrable experience, watch out for NDAs – you may wind up with three years of awesome GH experience that you can only discuss in the broadest of terms.
  • Of course, if the company doesn’t already have a growth hacking mindset, you’re rolling the dice that you can win them over.

Money Risk: Extremely low – you’re on a (presumably) competitive salary

Speed to experience: Very low in the right environment, surprisingly high in the wrong one


Screw working on someone else’s high-traffic site, just build one for yourself! Generating your own site with five-digit-plus uniques a month is certainly not easy, but once you’re there…


  • You can experiment to your heart’s content, with no politicking necessary.
  • If your website is related to growth hacking, it’s a double-win (Bronson Taylor seems to have done this very effectively with
  • You now also own a valuable web property!


  • See above – “Generating your own site with five-digit-plus uniques a month is certainly not easy.” :)
  • If you screw up, it’s your wallet that takes the hit.
  • You may find yourself too busy maintaining the success you’ve created to get the growth hacking experience you originally set out for.
  • Getting a taste of independent success may take you off the “growth hacker” track and put you on the “entrepreneur” one.

Money Risk: Very high. This is all your own elbow grease.

Time Risk: High until you can get it off the ground, then very low after.


Get paid for gigs in whatever you’re already good at, but only take on ones that give you growth hacking experience on top. For example, if you can close deals as a UX designer providing wireframes, you can do so only under the condition that the final product is rolled out as a split test and the results are reported back to you.


  • You can chart your own destiny without risking significant time or money.
  • You can work with a variety of companies, on your terms of future disclosure.
  • It may be easier to land future contracting gigs when you’ve already established yourself as a successful consultant, rather than a successful part of an in-house team.


  • This will likely require you to turn away a significant amount of deals.
  • You may not have full control over how the experiments are conducted.
  • You will need to manage two careers in parallel while making the transition.

Money Risk: Low, provided your non-GH skills are in demand – you can always take on “regular” gigs if you need to.

Time Risk: Medium, provided you don’t take on the aforementioned “regular” gigs!

How Basecamp Onboards New Users

37signals is renown for producing clean, no-nonsense products, and their onboarding experience is exactly that. They also have a very cool tactic for getting new users acquainted with the interface!

User Onboarding Deep Dive: LessAccounting

I recently signed up for LessAccounting, and documented my experience with screenshots and annotated recommendations!

Screens Are Obstacles

Don’t forget – 100% of the friction in a conversion funnel is stuff we put there

A lot of times, a conversion funnel will be defined by identifying the different parts of the interface a user has to interact with in order to complete the task at hand.

For example, a typical onboarding funnel might look something like this:

  1. Click “Start a free trial” CTA
  2. Fill out signup form
  3. Confirm email
  4. Accept terms & conditions
  5. Enter credit card info
  6. Start using the product

There’s usually a screen for each step, with each screen designed to help people advance to the next. With six screens in the setup process above, that must be a lot of help, right?

Well, no, not necessarily. If you pay attention to the amount of people who start with step 1 and make it all the way to step 6, you will definitely see that not all do. In fact, there’s going to be at least some dropoff for each and every step.

Here we have six screens that are designed to get people onboarded and ready to go, but each of the steps they represent are taking some otherwise engaged people off the table.

Seen from that perspective, screens – generally thought of as advancers – might really be better thought of as barriers; the only way to achieve 100% conversion from one screen to the next is to remove that screen entirely.

A Tale of Two Workflows

Contrast the following two workflows for getting photos off your iPhone and onto your computer:

iPhoto’s Workflow

  1. Connect the phone to the computer via USB
  2. Open the application
  3. Select the photos you want to import
  4. Toggle checkbox to group events by date
  5. Click either “Import All” or “Import Selected”
  6. Wait while each photo imports
  7. Click either “Delete Photos” or “Keep Photos” to finish
  8. Have photos on computer

That’s a lot of opportunity for distraction, confusion, anxiety and abandonment – and this is from a company that’s kind of known for good design!

Here’s the other one:

Dropbox’s Workflow

  1. Connect the phone to the computer via USB
  2. Have photos on computer

That’s really it. It throws you a passive notice that it’s pulling them into your Photos folder and then just churns away in the background.

Both workflows get us to the outcome we want, but Dropbox tessers us there directly.

What Are Funnels For?

A funnel should exist to facilitate a real-world change in a person’s life:

  • They had to find a place to stay for an extra night in a city they weren’t familiar with and booked something awesome.
  • They wanted to communicate something to their audience and now it’s sitting in all their followers’ inboxes
  • They didn’t know if there was enough money in their checking account for a nice dinner out and now they know.

The point of a workflow isn’t to get people from Point A to Point B in your app; it’s to get people from Point A to Point B in their lives.

When you define a workflow by its steps rather than its outcome, you’re taking an activity that’s supposed to be about a user’s progress and defining it by the impediments preventing it instead.

Like what’s illustrated in the image up above, don’t equate a conversion with “the fabric the ant has to traverse”, identify it as “getting from one hand to the other”, then be ruthless in making that as straightforward as possible.

Life Inside Dave McClure’s Pirate Metrics Funnel

Dave McClure’s “Pirate Metrics” funnel has been lauded by many, and adopted as something of a default model for SaaS customer metrics.

Its name comes from combining the first letter of each of its stages (Acquisition, Activation, Retention, Referral, Revenue), which spells out “AARRR”. You know, like what a pirate says.

Businesses find it useful for tracking how well they’re converting strangers into full-fledged, money-spending evangelists. But when viewed from the perspective of someone going through the process of becoming a customer, the experience is quite different.

A View from the Inside

While names like “Activation” and “Revenue” are easy ways for a company to describe the current status of any of its customers, those words are meaningless when applied the other way around: no part of becoming a customer “feels” like any of the stages as they’re named.

For example, this would never happen:

Person 1: “Hey, how are things going with building up your newsletter list?”
Person 2: “Pretty good! I’m in the Retention stage of my relationship with MailChimp right now.”

Put simply, the terms the AARRR funnel uses are completely out of alignment with the experience of becoming and remaining a customer.

This may not sound like a big deal, but the issue is as foundational as it is subtle: when the way you view your relationship is out of alignment with the way the other party views it, that relationship is in severe jeopardy.

A Funnel on Their Terms

Think back to a recent time you became a customer of a SaaS company – what was the process it took to get there? How would you describe it from your own perspective, rather than the company’s?

I’d be willing to wager it would be pretty different in at least two ways:

  1. The process would be centered around your relationship with a recognized need, not with a particular company
  2. Your relationship with the need would go back long before the company came on the scene, and continue long after you started paying them

In other words, MailChimp’s customers don’t view themselves as part of the MailChimp customer base, but the reverse – they view MailChimp as just a part of fulfilling their greater need.

To me, the latter is a much healthier perspective for a company to take. Rather than limit the scope of “relationship progress” to what customers can do for a company, why not invert it and chart out all the ways a company can help further the customer’s relationship with their greater need?

This keeps you laser-focused on the central reason people become your customers to begin with, and also diversifies your ability to bring value to them.

For just one example, consider what people are struggling with before they search for a solution to purchase. How can you help them in that earlier phase and frontload your relationship with value? How much of an advantage would that give you once they’re ready to buy?

Of course, this is not to say that all company-centric metrics should be completely banished. They have their place and their utility, when kept within their proper context.

Just keep in mind that your customers aren’t living in your funnel, they’re living in the real world. Fortunately, you can live there too.

Exploring the Problem Space

For every product, there’s an underlying need it exists to serve. I call this underlying need the “problem space”, as it’s an “area” that a solution can cover.

Problem spaces exist independently from the products that serve them. While VCRs, DVD players and online streaming have displaced each other, what never changed was the problem space they were all designed to cover: people wanting to watch movies at home.

It’s crucial not to mistake the problem space with the product itself, as Apple’s Jony Ive so eloquently points out when talking about redesigning school lunchboxes:

“If we’re thinking of lunchbox, we’d be really careful about not having the word ‘box’ already give you a bunch of ideas that could be quite narrow. Because you think of a box as being square, and like a cube. And so we’re quite careful with the words we use, because those can sort of determine the path that you go down.” - Jony Ive

The problem space a lunchbox serves is transporting food from one place to another. Nothing about that requires it to be cube-shaped, but by naming it a box at the onset, the field of possible solutions becomes artificially constrained.

Defining a product by “what it is” in the absence of “why it is” leads to narrow, inflexible and short-term thinking.

And it happens all the time in web design.

The Feature Is Not the Problem

For example, a sign-in form’s underlying purpose is so ingrained that it almost goes without saying: it authenticates users.

However, when defining a product scope, that underlying purpose shouldn’t go without saying: by only stating “here we need a sign-in form,” you define the solution and only imply the purpose behind it.

If instead you first define the purpose by saying “here we need to authenticate users,” how might that expand the field of possible solutions to the problem?

Maybe you could authenticate by social APIs instead. Or by text message. Or gesture/face/voice recognition.

All of those approaches may address the “authenticate users” problem as well as a sign-in form could, but would never have been in the mix were it framed solely as “we need a sign-in form” from day one.

Holding Features Accountable

Defining solutions by “what they are” in the absence of “why they are” also makes it very tricky to assess their performance: if a sign-in form’s only requirement for success is “be a sign-in form”, how could you really determine whether it was doing its job well or not?

If the desired outcome was instead specified as “authenticating users”, you could very easily come up with ways to track how successful the thing you built was:

  • The rate of successful authentications per attempt
  • The average time users spent trying to authenticate
  • The frequency of support/recovery requests relating to it
  • etc.

The measurements above could be applied to a sign-in form as easily as they could to social API authentication; they’re result-driven, yet feature-agnostic.

Iterating on results rather than features is a much more powerful approach to product development than simply ticking a box that says “feature complete” and moving on to the next thing to build.

Greater Than the Sum of Its Parts

When designing a product, progress should not be conflated with generating functioning features, but rather effective ones.

A feature’s not “complete” once it’s QAed and deployed – that’s really just the start. It’s complete once it successfully covers the problem space it exists to serve.

Rather than define a product’s scope as a list of features and requirements, consider instead first defining it by its problem space, and the indicators that will let you know when it’s been served.

Harnessing Intents

People are the engine that makes your website go. Understanding and serving them will help it go far.

Every time someone pulls up a website, it’s for a reason.

The reason might be anything from checking their account balance  to sending out a newsletter  to seeing a picture of their niece, but whatever it is, it’s there, and it’s kick-starting the whole experience.

This goes for not only your own website, but also literally every website anyone’s ever (intentionally) visited. There’s always a reason.

I call those reasons “intents”, and I consider them to be the core planning element for a successful website design.

Intent Architecture: Better Than Information Architecture

While the usual website planning documents are focused on describing how its sections and content will be organized, they don’t really outline why they should exist to begin with.

Whenever working collaboratively, leaving web content’s raison d’être open to personal interpretation is not ideal, especially if the early decision-maker isn’t going to be involved in each stage of production.

Architecture that starts with defining the purposes that the website will exist to serve not only sets it up for being better-aligned with the user’s expectations, it also makes it very easy to hold each of its sections and parts accountable for results.

Putting Intents into Action

Find intent-serving nirvana with these 8 steps:

  1. List out all the intents people might be bringing to your website.
  2. Validate the list with your actual audience.
  3. Rank the intents by how valuable they will be to serve (for both you and your users).
  4. Starting at the top, break each intent down to its minimum workflow (you can start with just a few).
  5. Measure the conversion baseline for each workflow the website currently supports.
  6. Pick a single workflow and create/rework website sections, screens and elements to better facilitate each of its steps.
  7. Roll the changes out as an experiment if possible (e.g. an A/B test), and measure the success rate of the people using it as compared to the baseline in step 5. Iterate until you get it where it needs to be (or better!).
  8. Rinse and repeat steps 5-7 for each intent you have listed.

Ultimately, the point of designing a website isn’t to “have a website” – it’s to facilitate activity. Beginning with intents keeps everyone focused on creating for the activities, and not just creating the thing itself!

What Do You Make Me Better At?

For a SaaS offering, it’s the first and most important question to answer

A lot of video games offer special power-ups. When you buy them, your character gains a new power.

Much like in video games, people in the real world buy personal upgrades all the time. They’re called SaaS subscriptions.

I Buy Software to “Upgrade” Myself

Try thinking of SaaS offerings as power-ups instead of products:

  • Zendesk makes me better at talking with customers
  • Workflowy makes me better at organizing my thoughts
  • Evernote makes me better at remembering things
Name, logo, value prop & how-tos: all about remembering

In that light, companies are better described as capability enhancers: Wufoo isn’t a form builder, it’s a power-up that makes me awesome at receiving feedback from my audience.

People come to you because they recognize an area for self-improvement. And, if you’ve positioned your company just right, they can see an upgraded version of themselves on the other side.

Your Company Isn’t Your Product, Your Company Is Who Your Product Produces

People don’t buy pencils because they want to have pencils, they buy pencils because they want to be better at writing.

When you focus on the specific thing you make people better at, all other aspects of your company easily fall into place: the branding, the value proposition, and even the product itself.

With all due respect to Y Combinator, the endgame is not making something people want; it’s making people into who they want to be. The thing you make is just what gets them there.

You can almost think of your company as the apparatus that churned out Star-Bellied Sneetches, except instead of printing a star you’re enhancing a skill.

The bottom-left of this picture isn’t your business; the top-right is.

Your business doesn’t exist to upsell people, it exists to upgrade people. Focus on the latter, and the former will take care of itself.

Be the change they wish to see in themselves. They will happily pay you for the help.

Websites Don’t Blow, They Suck

Buckminster Fuller was a designer, a scientist, an inventor, and one of the most fascinating thinkers I’ve ever studied. He didn’t live to experience the world wide web, but I recently came across a passage in one of his biographies that perfectly applies to web design nonetheless:

When [he] announced that the wind “sucked”, his audience usually laughed out loud. The statement certainly sounded funny, but he was serious. Talking about the wind “blowing” deflects [our] thoughts from what is actually happening. No force can push a huge parcel of air around Earth any more than you can push a flock of ducks into a barn. In any case, what could be doing the pushing?

Nothing is doing the pushing; wind isn’t pushed. When you face the wind, you have your back to its cause. A distant low pressure area pulls denser air to itself, just as a bucket of feed in the barn will bring in the ducks. A “northwest wind” is actually a “southwest suck”.

We often talk about our work in terms of making things that make people take the actions we want — sign up for a newsletter, upgrade their account, take a survey, tell a friend — but the truth of it is, we’re completely powerless when it matters the most: that moment when someone, somewhere is actually putting our website to use.

People use websites to achieve what they want, in a way that they want. And if yours doesn’t serve their purposes, they won’t use it at all. User motivations are the only force driving an interactive experience; our designs don’t cause that momentum, they can only support one that already exists.

When you face the wind, you have your back to its cause.

I love that line. Which way are you facing?