Andrew Chen Archives

My friend Mike Greenfield recently started blogging, and I couldn’t recommend his blog Numerate Choir more. I also had him on my list of growth hackers from a month ago. Mike is (as of today) 500 Startups’s first “Growth Hacker in Residence” and before that, co-founded Circle of Moms (acquired by Sugar), and was a data geek at Linkedin and Paypal.

Some of his excellent recent blog posts:

• Why “A/B Testing vs. Holistic UX Design” Is a False Dichotomy
• Cutting the Facebook cord
• The Visionary and the Pivoter

And with his permission, I’ve cross-posted one of his recent essays below.

Enjoy!

No, you don’t need a real-time data dashboard*
By Mike Greenfield
Originally posted on Numerate Choir

When Circle of Friends started to grow really quickly in 2007, it was really tough for Ephraim and me to stay focused.

Many times over the course of a the day, Ephraim would turn and ask me how many signups we’d had in the last ten minutes. That might have been annoying, but for the fact that I was just as curious: I’d just run the query and had an immediate answer.

Rapid viral growth can be unbelievably addictive for the people who are working to propagate it. You tweaked a key part of your flow and you want to see what kind of impact it’s having — right now. You’ve added more users in the last hour than you’ve ever added in an hour before, and you wonder if the next hour will be even better.

That addictiveness can be a great asset to growth hackers; I’d argue that anyone who doesn’t have that sort of jittery restlessness probably wouldn’t be the right fit in a growth hacking role. Restlessness is a huge motivator: I want to grow the user base, so I’m going to implement this feature and push it out as quickly as possible just so I can see what impact it will have. And if this feature doesn’t work, I’m going to try and get something else out before I leave the office so I can see if I’ve uncovered something else before it’s time to go to bed.

One day, I came up with a feature idea as I was walking to the train station in the morning. I coded it up and pushed it out while on the 35 minute train ride. There was a ten minute walk from the train station to my office; by the time I got to the office I saw that my feature was increasing invitations by around 20%.

I loved telling that story to potential engineering hires.

Here’s the thing, though: if everyone in your company behaves like that, you may acquire a huge user base, but you’ll likely never build anything of long-term value. You’ll wind up optimizing purely for short-term performance, never moving toward a strong vision

Back during that Circle of Friends growth period, I decided to automate an hourly stats email to Ephraim and myself. It satisfied our curiosity about how things were growing right now, but it stopped me from running SQL queries every five minutes. At least in theory, that meant we were focused on real work for 58 minutes every hour. In retrospect, it seems ridiculous that we needed stats updates every sixty minutes, but that actually was an improvement.

My distracted experience is why I worry about the effect of analytics companies that now promote a real-time dashboard as an awesome new feature.

It’s technically impressive that they’ve implemented real-time functionality. And at first glance, it’s very cool that I as a user can log in mid-day and see how stats are trending.

But the key distinction — and about 60% of analytics questions I’ve seen people ask over the years are on the wrong side — is if you’re looking at stats now because you’re curious and impatient, or because those stats will actually drive business decisions.

I’m afraid that in most cases, real-time stats are being used by people who aren’t iterating as quickly as growth hackers. The “need” for stats is driven more by curiosity and impatience than by decision-making.

Execs who are making big picture decisions are probably better served by looking at data less frequently. Growth hackers and IT ops types can and should attack problems restlessly — a big part of their job is optimizing everything for the immediate future. But executives are best-served waiting (perhaps until the end of the week), so they can take a long, deep look at the data and think more strategically.

This last weekend, I watched Steve Jobs: The Lost Interview (It’s available on iTunes for $3.99 rental). It’s great for many, many reasons, and I wanted to write an important point I seized upon during the talk. Here’s the link, if you want to watch it yourself.

Let’s start with an important quote:

“Insanely great”

That phrase is one of the most confusing things about the Apple philosophy, and I think it is commonly misinterpreted. Product designers often use it as an excuse to endlessly work on their product, with no release date or eye on costs. It becomes the reason why people want to focus on building completely new products and avoid copying competitors.

Apple has done a lot of stealing and reinventing
Yet in the interview, Steve Jobs has lots of interesting anecdotes:

• Apple copying the graphical user interface from Xerox PARC
• The famous quote, “Great artists steal.”
• How NeXT was building web products, same as everyone else

He says all of this, while at the same time criticizing others for lack of taste and insulting their product quality.

Great products, regardless of source
To me, the way to reconcile this is that Steve Jobs cares first and foremost about great products. Sometimes the way to get there was to steal. Sometimes you reinvent and reimagine. And sometimes, you have to invent.

The point is, building a great product is about curating from the entire space of possible features you could build. Shamelessly steal ideas when they are the best ones. Ignore bad ideas even if they’re commonplace. Don’t think you have to build something totally different to make a great product.

I think this has matched with Apple’s strategy towards their most recent generation of products – though they didn’t invent the GUI, the mouse, the MP3 player, downloadable music, the laptop, or the smartphone, they’ve build some of the best products out there. (I’ll give them a lot of great for the iPad though, which is truly a new invention)

The craving for novelty in Silicon Valley
So for all the product managers and designers out there – if you are finding yourself wanting to do it differently just because, or trying to find novel solutions just because, then maybe your priorities are not in order. The goal of building great products is for you to deliver something great to the customer, not to impress your designer friends on what new layout or interaction you’ve just developed.

Make it insanely great, even while you copy, steal, reinvent, or invent whatever you need to make that happen.

Anyway, it’s a great interview and I think everyone involved in tech products should watch it.

Originally asked on Quora. If you find yourself mostly thinking about balancing satisfaction versus virality, you’re probably doing it wrong. The Quora question is a false dilemma, because it asks you to choose between satisfaction and virality, and then quantifying the tradeoff. Most of the time, if you’re working on naturally viral products, you spend most of your time elsewhere. The world of product decisions is more like:

That is, you have features in your product that either drive growth or don’t, and you have features in your product that either really help the value proposition, or don’t. These are actually pretty independent factors and you can build product features that hit each different quadrant. For example, if you are building a product like Skype, finding your friends and sending invites is clearly a high value prop, high virality action. After all, you can’t use Skype by yourself. But if you take the exact same feature, and try to bolt it onto a non-viral product like, say, a travel search engine, then you’re just creating spam. There’s really no great reason to “find friends” in a travel product, though it might be useful to share your itinerary. A feature that’s high-value in one product is spam in the other. And if you think about each quadrant, you get something like this: Let’s talk about each bucket:

• Awesome features grow your product and also people love them. The Skype “find friends” feature is a great one, but so is Quora’s “share to Twitter” feature. After I write this post, I want people to comment and upvote, so something that lets me publish to my audience, which is both viral and part of the value prop is awesome.
• Do it anyway features are just the core of your UX. Writing on walls on Facebook may not be inherently viral in themselves, but it’s important to the product experience, keeps people coming back, and indirectly helps drive the virality of the product. The more people you have coming back, the more changes you have for them to create content or invite people
• Spam features are high virality actions that your users don’t really want to do, and don’t add to the product value prop. I think this is the bucket that the tradeoff lives of a question like, “should I be viral, or offer a great product?” If you are spending a lot of time in this quadrant, then you are shaky ground.
• WTF needs no explanation

Ideally, you want to pick a proven product category that’s naturally viral and high-retention, for instance communication, publishing, payments, photos, etc. – and then spend as much time building awesome features that both drive growth and also make your users happy. Stay away from spam features as much as you can, or use them sparingly lest your product becomes spam.

[UPDATE: I have taken a much longer and more comprehensive whack at this problem in this deck:

How to build a growth team (50 slides)

Here, I answer a couple important questions:

• Why create a growth team?
• What’s the difference between a “growth hacker” and a growth team?
• What’s the difference between growth and marketing/product/whatever?
• Where should growth teams focus?
• I’m starting or joining a growth team! What should I expect?

Hope you enjoy it!

And for the previous answer, which I typed up on Quora some time ago, you can read below.]

So what does a growth team work on day to day? I would break down what a growth team does into two major buckets:

1) Planning/modeling
2) Growth tests.

Let’s dive in, but starting with the usual caveat – you need a killer product before you should start working on growth.

But first, you need a great product
Let me note that if people aren’t using your product, then you’re wasting your time spending too much time optimizing growth. You need a base of users who are happy and then your job is to scale it.

With that caveat in mind, let’s start with the planning activities:

Planning and model building
The planning/modeling side of things is really about understanding, “Why does growth happen?” Every product is different.

• You might find that people find you via SEO and then turn into users that are retained via emails
• You might find that people come to your site via web and then cross-pollinate to mobile, and that’s the key to your growth.
• You might find you need to get them to follow a certain # of people.
• You might realize they need to clip a certain # of links to get started.

These are all things that are product-specific, so I can’t give specific advice in this answer, but this is the foundation for understanding why your product grows. You can come up with a model by looking at your flows for how users come into the site, by talking to users, and by understanding similar products. You can look at successful users and unsuccessful ones.

Once you have a good model, you can create more specific criteria in evaluating the outcome of a good or bad growth project. Your mental model doesn’t have to be perfect at first- the goal is just to get started. As you execute your project successfully, if your growth goes up, then your confidence will grow. (Or you’ll have to revisit things if you keep improving that one metric significantly but overall signups doesn’t go up)

At a more tactical level, eventually this model gets more fine-grained and you can start thinking about individual things that you can change to increase overall growth. Ideally you can model a lot of this in a spreadsheet so you can do scenario-planning around what works and what doesn’t.

The goal is to create some kind of feedback loop that results in sustained growth. Maybe you buy ads, make money, and then reinvest even more in ads. Maybe you get people to create content, driving SEO, which brings in more people that create content. Or maybe you have something invitation based. The important part is to model this process and its component parts.

Project execution
Once you have a model for how to drive your growth, the next part is to actually come up with a bunch of project ideas that can make those numbers go up and to the right. Ideally you can do lots of A/B tests for pretty short ideas that prove out the concept. If it works out, then keep investing.

For something like this, you’ll need a bit of A/B testing infrastructure, a lot of creativity, and some dedicated engineers to get the tests out there.

Because the majority of A/B tests don’t do what you want (maybe the number is <30%) as a result, you’ll want to have many, many A/B tests going at the same time so that you get a couple winners every week. Sometimes people do 1-2 A/B tests per week and then complain that it doesn’t work for them – they probably need to 5-10X their A/B test output in order to get a win or two per week.

To execute each growth project, you may also need to develop some instrumentation around tracking where users come from, and what they do. This can be a bunch of SQL databases and reporting at first, but might move to something fancier later on.

Eventually, the results of these tactical projects feed back into the uber model – you have to constantly reevaluate your priorities and understand which places in the product are the most leveraged in driving growth. So there’s a feedback loop of jumping from the strategic to the tactical, and back.

Summary
To summarize the above:

1. Have a solid product where your users are happy
2. Coming up with a model for how your site grows
3. Trying out ideas and deploying them as A/B tests
4. If the site grows, then try out more ideas. If it doesn’t, rethink the model in step 1 because it might be broken

Hope that helps.