Andrew Chen Archives

Designing a viral loop has multiple stages
Viral loops have been featured in mainstream media and there’s even a book coming out on it – but the step-by-step design of creating a new loop remains obscure, and for good reason. I’ve come to believe that creating viral loops is akin to building a software project – at best, it still comes down to a great team, a strong understanding of the tools available, and relentless iteration. There’s no recipe at the heart of it which guarantees a viral process every time, the same way that you can’t guarantee that any software project will result in market success.

There are no silver bullets in viral marketing
In fact, the core of virality ensures that there will never be a dominant “recipe.” If everyone knows how to build a viral loop around social network invites, then everyone will do it, resulting in consumers will become desensitized, which finally leads to lower response rates. Thus this causes the viral loop to unwind, which leads to long-term disaster.

The only way to combat this is to build a viral loop around the core of your product – something that no one will seek to duplicate, unless they are a direct competitor. These viral loops are incredibly effective because they are lasting and sustainable.

I wanted to jot down a couple thoughts on the different stages that viral loop design go through, so that the entreprenurs reading through this can imagine deeply ingrained, user-aligned ways for their products to gain distribution.

Strategize: Stage 1
The first stage of a viral loop is developing the core strategy around the loop. This requires the viral loop designer to think through, step-by-step, how a user will come to find their product and how they will ultimately pass it along to their friends. If you’re lazy, there are lots of recipes to follow from the Facebook ecosystem like quizzes, “find your friends,” and gifts. As discussed above, these opportunities are already becoming less effective every day.

Even if you decide to use an existing recipe, here are some higher-level strategy questions that should be answered before proceeding:

• How does this viral loop fit into your core product?
• What is the fundamental value proposition you are presenting to your users?
• If your loop is successful, will users transition to your core product or will they bounce when reaching the switchover point?

As you might imagine, most of the discussion here is qualitative and there’s very little A/B testing involved.

Implement: Stage 2
The next stage is the rapid development of the core viral loop. This part should hopefully take days or weeks, not months. It will also certainly be wrong. The best advice I can give here is to follow agile development models and to build the smallest number of features and pages to create the initial flow of pages.

As mentioned before, the best implementations are strongly tied to the core product – as a result, if you’re a video site, it’s best if you can somehow involve videos. If you’re a dating site, you probably want to involve dating.

The other implementation advice I’ll give is to treat the viral loop code as an iterative, protoyping process. So copy and paste all you need, keep it in a separate codebase, and make it easy to refactor. You’ll need to do a lot of messy stuff like changing the order of pages or page elements later, and once you develop your own recipe, it’s easy to rewrite it in the “right way.”

Launch: Stage 3
The next step is to beg, borrow, or steal traffic :-) The easiest way is often to pay for it, $50/day or so, just so you have a trickle of traffic coming in.

Optimize: Stage 4
As you get a flow of incoming traffic, this allows you to deeply optimize the experience. This will involve building out some basic infrastructure to do A/B testing, or using Google Web Optimizer, and otherwise. The key thing here, of course, is to measure whether or not the $50/day you’re spending results in traffic above and beyond what you’re paying for – the more the better, and eventually you’ll cross the threshold where traffic scales infinitely.

In this stage, there are a lot of common fixes that you’ll want to consider:

• Shortening the flow of pages (can you shrink a 5 page funnel down to 2?)
• Rearranging UI elements to emphasize next steps
• Testing different value propositions for going through the flow
• Increasing the # of people invited

This optimization stage creates great conflict for product and customer-oriented people. Oftentimes, to get a number to move from 10% to 30%, there’s temptation to do things that users may not be happy with. This might include things like asking for invites multiple times throughout the initial session, presenting an opt-out process for selecting friends, etc. These are all bad and need to be fixed in order to create a long-term sustainable viral loop.

This optimization step can take a very long time (months is not uncommon) as you zero in on the dozens of small and large changes needed to create a viral loop.

After months of work, two outcomes can result:

• You don’t reach your goal, and you’re stuck on traffic
• You reach your goal, and your traffic is going bananas!

If you don’t reach your goal, then it’s time to stop your optimization process. Often the changes that result are just too small to drive substantial increases in metrics. Instead, you’ll have to rework your entire value proposition, which means to either go back to Stage 2 or possibly Stage 1. This means you’ll want to stop A/B testing and start building out a deeper featureset.

Refine: Stage 5
If your optimization step was successful, your work is probably not done. The final step is polishing your viral loop.

This includes figuring out issues like:

• Making your loop as user-aligned as possible
• Building a pleasant user experience and removing unnecessary flows or page elements
• Refactoring the code to move it from prototype to production
• Integrating it into your core product in a way that makes sense

A lot of people are tempted to skip this polish step, but don’t do it! Skipping this step means that your initial product experience will suck, or be offensive.

In fact, when there’s “excess” virality, that’s a great opportunity to make changes to the viral loop that make it nicer or friendlier. In general, if you are getting exponential growth, it’ll be great even if it’s a slower exponential. What’s more important at that point is spendfing your extra growth towards changes that positively impact long-term retention.

On the other hand, if your product is just meant to be short-term mad money, then by all means skip this step :-)

More on viral loops and marketing
For those that are interested, I’ve written more about viral loops and marketing here.

Today we have the first part of a fantastic two part series where Gambit, a microtransactions platform, is sharing exclusive data and analysis for the payments happening on their platform. The author, Susan Su (@susanfsu), is a writer, marketer, and Stanford alum who’s currently at Gambit Payments. She wants startups to make it big, and you to make more money. Enjoy! –Andrew

Age (and ARPPU) ain’t nothing but a number
by Susan Su, Gambit Payments

In the game of life, you’ve heard that age ain’t nothing but a number. In the world of social games and virtual currencies, the same thing goes. The smart developers know to segment by age groups and target towards those with the highest demonstrated ARPPUs. The even smarter developers know that age ain’t nothing but a number – a single, lonely metric that can dangerously limit your view when you exclude crucial supporting data.

In this post, we’re using demographic data from Gambit Payments to get a bird’s eye view of ARPPUs by age and transaction volume. We’ll see that age data – and even ARPPUs – mean little without the context of volume.

A look at highest grossing ages
Which users pay the most to play?

From this data set, you can see that Gambit’s developers got the highest ARPPUs with users aged 50+. In this month, 60 year old users brought in a $7.92 ARPPU, more than double the ARPPU seen with the younger set.

Players in their 40s averaged a $4.39 ARPPU range – a pretty impressive figure still. Going younger, players in the 30 to 39 year old range brought in a slightly lower ARPPU of $4.11 while players in their 20s brought in $3.07 on average. Finally, teenage players brought in ARPPUs in the mid-$2 range.

This data should come as no surprise. Let’s take a look at the main levers feeding into ARPPU:

• Income. How much money does this user or group of users make? In most respects, this lever is straightforward; if the user in question doesn’t pull in an income, they won’t initiate direct payment for your currency. But, that’s what offers are for. Note, however, that offers typically do not bring in the same flashy ARPPUs as direct credit card or PayPal payments.
• Access to which type of payment. What payment methods are available for this user or group of users? Since we’re talking ARPPUs here, a paying user is a paying user – and thus already has access to some type of payment. However, remember that not all payment methods deliver the same dollar value to your pocket.
  • Does this user or group of users have access to credit card payment or PayPal? If so, you’re in luck. These methods typically bring in the highest revenues because they’re relatively easy and impose minimal friction. Note that PayPal penetration may be low in some parts of the country and world, so it’s unlikely that PayPal will be your biggest breadwinner overall.
  • Will they be paying through their mobile provider? With mobile, money travels through lots of different hands – mobile aggregators, mobile operators, mobile payments providers – before it reaches you, a trickle-down process that will affect earnings accordingly. Also, keep in mind that mobile is based on fixed pricepoints, which gives you less flexibility for what people will pay for. Finally, when paying with mobile, there’s also a cap on a transaction’s dollar amount – you can’t, for example, pay for something costing $100 through your mobile service. While mobile payments typically bring in lower ARPPUs, they also have lower access barriers and are relevant to a wider swathe of your users.
  • Will they be completing offers to earn your currency? Offers can bring in decent ARPPUs, but, for certain user groups, may lack the longetivity of direct payment methods. Will your users complete offers, only to decide that they hate the experience and would rather abandon the process – or your community – altogether? How will you deal with this? For further exploration of this topic, see Gambit’s post on user complaints and coping strategies.
• Willingness to buy online. What is this user’s comfort level with online purchasing? If they’re uncomfortable with online purchasing, ARPPUs associated with this user or group of users will dive accordingly. This becomes a particularly interesting question when you start looking at other demographic data in addition to age – you may find, for example, that users in a certain geographic region are more comfortable with online purchasing because of variance in internet penetration or fluency.

If these levers sound familiar to you, you’re doing well so far. Now let’s see how each of these factors works in the context of the data presented above.

Older users
Older users not only have disposable income, they have access to the payment utilities – credit cards, mobile phones, PayPal accounts – that bring their money to your community. Why 60 year olds specifically? You should view the fact that 60 year olds were at the top as a datapoint specific to this set (an outlier) than a generality that should be extrapolated into rule. If you take a look at the groupings, the 50+ group still achieves an average ARPPU (across individual years) of $5.20 – pretty impressive.

At the other end of the spectrum, your community’s youngest paying participants probably don’t have jobs or the disposable income they bring. Their access to direct payment methods is likely to be highly limited or nonexistent. On the other hand, they probably do have access to mobile payments, and can always complete offers. Based on the notes above, you know that payment via mobile and offers will mean lower ARPPUs for these users.

The key here is to know your users – Who are they? How much money do they make? Where do they live? What types of payment methods are available to them, and how willing / able are they to engage with different methods?

Revenue breakdown by age
Finally, does all this mean it’s time to regroup your acquisition efforts and start to go after the 50+ set (or, if you have been already, give yourself a hearty pat on the back and quit working so hard)? Not yet. Let’s take a look at the percentage of total revenue that these groups bring in, respectively.

It turns out, despite impressive ARPPUs, the 50+ group makes a sad showing when we start looking at percentage of total revenue. If we’d halted our analysis at individual ages, or even broader age groupings, and the ARPPUs they demonstrated in this data set, we would have missed the point entirely.

Transactions breakdown by age
For Gambit developers, 50+ was the goose that never laid its golden egg. All the users in this entire group represent only half a percentage point of Gambit developers’ total revenue for this period. This isn’t because there are 200 age groupings, either. Let’s take a closer look.

Wow. The 50+ group represents a meager 0.3% of total transactions – a figure so small that it barely registers a speck on the revenue radar for Gambit’s developers. Users in their 20s, by contrast, produced 22.5% of all transactions. Finally, teen users represented a whopping 73.5% of transactions made across all Gambit developers. 73.5 versus 0.3… suddenly that $7.92 ARPPU doesn’t seem so significant anymore.

What’s good about the user groups bringing in lower ARPPUs, and how do you optimize their experience to impact your revenues? Conversely, is it possible or worthwhile to improve transaction volume for the highest ARPPU groups? In next week’s post, we’ll go over the strategy implications of the data we presented here and contrast a few approaches to make you more money.

For data geeks
If you prefer to look at the above data in a neat table instead of a fancy pie chart, here it is:

Hope you enjoy this data from Gambit Payments, and part 2 of this article will be coming soon!

[Andrew: Thanks again to Susan for putting together this great post!]

Want more?
If you liked this post, please subscribe or follow me on Twitter. You can also find more essays here.

A quick rant:

Every time you talk to an ad network or leadgen network or whatever, if you ask what their differentiation is they will say “targeting.” That’s probably wrong, and let me tell you why, based on the recent announcement of the Netflix prize winners:

Netflix was able to wring three years of research to nudge its recommendation algorithm up 10.5 percent, at a cost of $1 million in prize money — a stunning feat on its own.

This means if you combine dozens of the best machine learning people in the world, some of the cleanest datasets, you get a measly 10.5% increase. Compare this to starting a new ad network where you end up with noisy datasets, lots of crappy traffic, and a small team looking at the problem – that’s not an easy path to disruptive change. In general, 10% is not a big enough number to counteract the other economic drivers in the ad market, which revolves around better deal terms, a larger selection of advertisers, better ad inventory, etc.

I would guess that you need a number closer to 50% lift or higher in order for an upstart to dramatically change the ad landscape and neutralize the weapons of the mass of ad network players.

I think disruptive change will come not from algorithms, but rather two other areas:

• Better ad inventory: New websites and mechanics emerge all the time, and who knows what happens when you put ads on them? It was clear, until they tried it, that with the right ads search can be >30% clickthrough rates or more, which is unheard of.
• Better data: The other big opportunity is in using specialized data to drive your algorithms – rather than basing everything off of domains, cookies, and ad impressions like everyone else, there may be ways to extend the targeting to unique datasets that no one has access to. This is what’s happening in the world of retargeting.

The Netflix prize also included people adding in additional data, and that’s factored into the 10.5% improvement. Anyway, the point is, increasing performance on stuff like this is very hard, so when an ad network tells you about their targeting, you should push them instead on their revenue split ;-)

If you don’t watch out, after a couple months of A/B testing, your product will end up looking like Las Vegas!

Why A/B testing and visual design come into conflict
It’s great to implement consistent A/B testing in their product process, but then it becomes even harder to keep a consistent visual design while doing test after test. This tension comes from the fact that A/B tests push you towards local maxima, making the particular section of page you’re testing high-performance, but at the expense of the overall experience. As a result, there’s a lot of temptation to “hack in” a new design, the way that software engineers have to “hack in” a feature – but this is short-term at best. This often means adding a bold, colored link to the top of page with “NEW!” or adding yet another tab – these are all band-aid solutions because once you get to the next set of features, it’s not a scalable design to have 100 tabs.

Each of these competing features, taken by itself, moves the needle positively. However, there isn’t a great way to measure the gradual “tragedy of the commons” effect to the overall user experience. Each new loud page element competes with all previous page elements, and must be louder as a result – this leads to the Vegas effect that many Facebook apps end up in.

To really solve this problem, you need a central design vision – there’s no way around that. It also helps a lot to have a flexible design that embraces A/B testing – you can work with your designers to make this happen through modular, open elements.

Closed designs make it hard to add or remove content
Let’s take a particular example and look at it – this might be a standard example on a page like a video or otherwise:

It looks nice, but also has tremendous sensitivity to the content and an inflexible design that makes it hard to test new content. To be more specific, ask yourself the following quesitons:

• If you wanted to add a comments count in addition to views and votes, how would you do that?
• What happens when the views number gets beyond 10,000?
• What if you wanted to add favorites, or flagging for inappropriate content?
• If we decided to hide the thumbs down, how would this visually balance?
• If we wanted to fit more thumbnails onto a browse page, how easy it is to shrink the main thumbnail?
• etc.

The above design is an example of a “closed” design where everything fits just right, but makes it very difficult to add or remove elements. There’s an exact balancing of all the parts of the element, which makes it very sensitive.

Many of the solutions to the questions involve either require building out new pieces next to the element, which throws it off balance. Thus, if the above were used in an A/B test, the visual look would be immediately ruined.

Open designs that are A/B test-friendly
Let’s compare this to the elements below, which have a more modular design that can scale vertically:

The above elements don’t have the same “just right” visual appeal, but make it much easier to add and remove content. The key design decision is to add multiple bands of content which can be grouped together and extended vertically. Ideally, you would never end up with a repeating tile of 4-buttons and 3-stats, but you could certainly test it much more easily than with the closed design.

Here are some of the variations that can easily be tested:

• Switch the title section and the stats/buttons sections
• Add and remove buttons (or no buttons!)
• Add and remove stats (or no stats!)
• Combine price tags with other stats
• Try different buttons
• etc.

Following an open design on page elements enables substantial A/B testing within some flexible constraints. Now you may still be tempted to do something crazy like big hover overlays, <BLINK> tags, and other stuff, but at least you can make it easy to test a wide variety of low-hanging fruit. It also makes the owner of the overall visual design able to maintain a central “style guide” while still offering enough flexibility to keep people creative.

This same idea of open designs with horizontal bands of content can be applied to whole pages too – let’s examine a page from the king of A/B testing, Amazon.com.

Open page layouts
From the snapshot below, you can see that Amazon groups the center column of content – each element has a title explaining how it is, a list of items, and a navigation link to see more. This is also true with the item detail pages, which use a similar grouping to show everything from similar books to reviews to other elements. These pages can get very long, but because most of it is below-the-fold, it’s easy to get away with.

I’ve been told that this modular design enables Amazon to take a “King of the Hill” approach to testing each horizontal band of content against each other. Different software teams will create different kinds of navigation and recommendation, and if it causes people to click through to buy, then it floats up higher in the page. This systematic A/B testing is much more easily enabled when there’s the design flexibility for that sort of thing.

Here’s a snapshot for a reminder of what this looks like:

While you may argue that Amazon’s design is cluttered and actuallysucks, on the other hand, this approach lets them take a very experimental approach to pushing out features. It makes it very low-cost to implement a new recommendations approach and try it out without needing to figure out how to design it into the UX.

What’s next? Modular user flows?
Of course, if you can take a modular approach to scaling individual page elements or entire pages, the next question is whether you can take this approach to user flows.

I’ve never seen anyone do this, but this is how it might work:

• Any linear user flow is identified in a product (like new registration, payment flow, etc)
• This flow might be 1 page, or broken into N pages
• Similarly, every individual page might have a bunch of fields (like photo, about me, etc.)
• As part of the A/B testing process, you might want to drop a new page (or new fields) into the flow
• Then an optimization process shuffles pages throughout the flow to identify the best page sequence and page-by-page configuration

You might imagine something like this could be a very powerful process as it would allow you to identify whether you should offer a coupon pre-transaction or post-transaction, or on any given page, where an input field should be placed.

For those who want to know more, I have written a bunch more about A/B testing here.

Want more?
If you liked this post, please subscribe or follow me on Twitter. You can also find more essays here.

Pretty fascinating slides – it’s 128 pages, but worth flipping through – see below. Those on RSS feeds, you can find a link to the presentation here. I found this via Bob Sutton, who writes:

This slideshow was on a number of blogs over the summer (see here) , but I wanted to make sure that everyone saw it and, frankly, to get a post here so I have a record of it.  Apparently, Reed Hastings, the amazing CEO of Netflix, put-up a set of 128 slides that is a “reference guide to our freedom and responsibility culture.” I realize that most 128 page slide decks are deadly dull, but this is an exception.  You may not agree with all their values and approaches, but on the whole I think you will be fascinated by the detail and thought.  Now, I have no inside knowledge of what it is like to work at Netflix, but if this is accurate, it is a pretty impressive company — frankly far more enlightened than most in SiliconValley.

Low-fidelity prototyping versus high-fidelity prototyping

In my discussions with designers, one of the interesting recurring conversations is the tools and process they use to prototype and mock up experiences. In particular, there’s a lot of divergence on how high or low-fidelity to go with a prototype.

For designers that primarily come from agency backgrounds, I’ve found that there’s an emphasis on quickly getting to a near pixel-perfect mockup, and the variations are minor in detail. In that worldview, the ideal deliverable is a single version of something that feels high-quality and gets minor feedback from clients. In the client-agency model, if you give your clients a bunch of rough mockups that seem low-fidelity, then you risk looking unprofessional. Or worse yet, you might get a ton of diverging comments that you then have to work out and iterate – in some cases that’s the last thing you want to do.

This is especially not a good situation for companies that focus on products delivered to customers –  in that case, you mostly want your product to be the right one, no matter how many iterations it takes. As a result, low-fidelity prototyping can be really useful because it aids an iterative, customer-focused approach rather than one where the Great Designer comes up with something directly from his brain.

Here’s a couple of the main advantages:

• Get better and more honest feedback
• It’s great for A/B testing
• Make the cost of mistakes cheap, not expensive
• Refine the page flow, not the pages
• Figure out the interaction design rather than the visual design

In addition, after I’m done arguing my point, I’ll recommend some of the tools that have been useful for me in doing low-fidelity prototyping.

Get better and more honest feedback
The first time I really undestood the power of low-fidelity prototyping was when I started doing usability tests on consumer products I had built (This was years ago). Initially, I wondered why anyone did paper-prototyping? I immediately concluded that it was due to a deficiency of many designers that they couldn’t write code, and thus couldn’t do HTML mockups of the products they wanted to build.

But once I started getting people to view and interact with my prototypes, I realized that one of the big problems was that people didn’t give good feedback when the prototype you present to them is too perfect. Rather than telling me about the really high-level things, like “does the value proposition make sense?” instead they would focus on colors, fonts, the layout of the page, etc. And furthermore, they didn’t feel that they could really jump in and build on top of the ideas you showed them, because it was far beyond their capability to duplicate.

Compare this to a simple exercise where you are using hand-drawn cards or drawing paper and are literally sketching stuff out during a customer interview – you’re much more likely to try something out, and have the person you’re interviewing grab your pencil and say “no, more like this!” And that’s exactly the kind of interaction you want.

It’s great for A/B testing
As for as a metrics-driven approach goes, you have to remember that techniques like A/B testing fundamentally thrive off of variety. In particular, it thrives off of variety at the UI layer, where many small UI changes that cost very little technically can be tried out and optimized. As a result, you don’t want 2-3 pixel-perfect mockups, you actually want 10 or 20 rough mockups where you can select only the most high-variance candidates.

Some of the highest variance stuff has to do with changing the order in which you do things, or opt-in versus opt-out, or richer AJAXy interactions. These are all things where it’s easier to generate many candidates through low-fidelity prototypes since you’re often looking at things form a systems level.

Make the cost of mistakes cheap, not expensive
One of the hidden benefits of having a low-fidelity prtotyping process is that it makes changing directions much easier, which naturally facilitates a collaborative design discussion. When you’re using a customer-driven product philosophy that incorporates a lot of outside metrics and qualitative feedback, you’ll probably get multiple people involved in the design process. If it’s done by one person or a small group, and is polished significantly before it reaches the greater group, one of the problems is that it discourages collaboration. It’s very hard for people not to get defensive when they’ve spent a lot of time polishing something only for it to get changed significantly. Using a low-cost process makes it so that you can try a lot of variations cheaply, without any of the emotions involved.

Refine the page flow, not the pages
One of the highest leverage design  decisions you can make is not about the look of an individual page, but what happens before and after it. For example, you can take a multi-step process and condense it onto one page, or change the ordering of something so that you do something and then register, rather than the other way around. These kinds of design decisions ultimately focus on the order and flow of the user, rather than the look or interactions of any specific page. If you go with a low-fidelity, then it’s easy to draw lots of small pages and link them up in a flow, and do things like cross pages off, change the ordering of a funnel, and lots of things that feel natural when the prototype is very rough. Otherwise, it’s too easy to get caught in the details on the “right” way something works without exploring the options.

Work your way up from low-fidelity to high-fidelity
Of course, you want to make sure that you use the right process for the right job. So there’s nothing wrong with high-fidelity prototyping, especially when you are in the later stages and thinking about issues like branding, look and feel, and all those other details. One way to keep this process going is to have multiple rough prototyping checkpoints so that design decisions are constantly getting refined – maybe the first step is a sketch on a paper, the next is a rough mockup on the computer, then a detailed mockup, then a rough built-out version, and then iterate to the final product. These steps make it so that all the design decisions are well understood, refined, and debated all the way through.

Tools I recommend
Finally, a couple recommendations on tools for paper prototyping:

• Number 2 Pencil :-)
• Giant art pad for drawings – you can get these at an art shop or office store
• Balsamiq (check out the video on the linked page)
• Macromedia Fireworks

In general, nothing beats pencil and paper, but that’s just me ;-) I’ve been told that for people who aren’t comfortable drawing, using tools like Balsamiq helps quite a bit.

Want more?
If you liked this post, please subscribe or follow me on Twitter. You can also find more essays here.

Seed funding and building out the initial team

One of the most exciting events for a startup is landing seed funding, which transforms a “2 dudes in a living room idea” into something with much more potential. I wanted to summarize a couple things that are relevant for this stage, learned from personal experiences and conversations with other entrepreneurs. This blog is targeted at startups who have raised their first $500k-1M of funding, which often leads to hiring 4-6 people – this first batch of folks is critical, of course.

Here’s a quick outline of some of the things I’ve encountered:

1. Hiring T-shaped people versus specialists
2. Try to get doers
3. More candidate flow solves a lot of problems
4. Interview for the actual work you’ll be doing, not skillset trivia
5. Raw intelligence is just one factor – don’t overestimate it

There are many more topics, of course, but this is a good start – let’s dig in:

Hiring T-shaped people versus specialists
One of the truisms in startupland is that everyone has to wear many hats – backend programmers might have to pitch in and do some feature work, designers might have to write some marketing copy, and the CEO might have to vaccuum the office ;-) Just as importantly, if you believe that startups are fundamentally undergoing a process to learn about their customer and the market, then you need people who are  versatile who can see distant connections between a variety of topics. So you want generalists, but a specific kind.

I’ve come to believe that the first batch of people you want on your team are going to be T-shaped, meaning they are broad in a bunch of different areas and deep in a particular one. The breadth of skills gives them enough common context that they can have conversations with anyone on the team about anything, but the depth gives them a source of knowledge that makes them vital to the team.

Testing for this can be as simple as asking a deeper set of questions when interviewing candidates, and asking them to do exercises that are outside of their stated skillset. Most engineering interviews are specialized enough that there are coding questions, but not many that I’ve seen also include an interview around product creation or UI design. Similarly, when discussing candidates, you’ll want to give equal weight to their depth area as their breadth areas.

Watch out for people who are so deep in one area that they seem to be overspecialized – it can be a signal for a lack of interest for pitching in on areas that might be vital for your team, or they may have nothing to do if your startup inevitably changes directions.

Try to get doers
It’s very important to hire people who are execution-focused early on. You just don’t have a lot of room for senior people or “philosophers” that don’t immediately contribute value in the product development process. When it comes to seniority, I’ve often liked to hire people who have recently had titles as team leads or directors, but nothing more senior. That way, you get people who are used to the responsibility of leading a team, yet are still low enough to the ground to have immediate impact. This is why people who are fresh out of consulting or banking backgrounds make for impractical partners – they are too focused on strategy and financials when you really should be focused 100% on concrete products and customers.

The other type that you find that’s not execution-oriented is the philosopher type. These folks often interview really well, are familiar with a wide spectrum of things and often experiment with new technologies all the time. The hard part about adding these folks to your early team is that they may be more interested in reading blogs and indulging themselves intellectually than really working hard on a team to get a lot of work done.

More candidate flow solves a lot of problems

For most seed stage startups, getting the first 2-3 people usually won’t be a problem – you’ll have people in mind, or people who are in your immediate group of friends who are easily accessible. What’s much harder is once you move beyond your immediate network, where you may find:

• People you want have jobs and aren’t interested
• As an entrepreneur, you know lots of entreprenurs who want to start something, not join something
• Lots of “OK” people who are interested, but who are hard to get jazzed about
• etc.

It’s easy to immediately get into a state where bars get lowered, things you don’t want to get accommodated are, and all sorts of other problems. Or you’ll have interviews where the person was OK but not great, and you really want the skillset.

All of this hand-wringing can be solved if you find a repeatable model for contacting qualified people and getting them in the door. I’ve found that when you start hiring for a new job role, it’s hard to figure out who a perfect candidate is – it isn’t until you see 10 candidates that you start to hone into what you really want and like. Figuring out the repeatable process that works for you is the hard part – but you want to find communities where your ideal candidates are already involved, and start talking to as many of them as possible. This may be Newgrounds for Flash people, or the Firefox extensions directory for browser folks.

Interview for the actual work you’ll be doing, not skillset trivia
I’ve previously written a bunch about my feelings on this topic, so I’ll just link here. The short of it is that I think most interview processes suck because they aren’t actually tests of what it would be like to actually work together. The ideal interview, imho, is just to interview, then work together for 2 months and do a checkpoint to see if it’s working OK. But because most people looking for a job aren’t willing to do that, having a 3-day “working interview” is a reasonable substitute as well.

Raw intelligence is just one factor – don’t overestimate it
All the young, energetic entreprenurs I know want to hire other people like them – high-horsepower people who work hard. As a result, you can organize an entire hiring process around intelligence, full of puzzles and brainteasers, and reward anyone who thinks quickly on their feet. I’ve found that this actually sucks as a minimum bar for hiring people – it’s just as important to evaluate things like passion in the area you’re working in, their reasons and goals for being at your startup, etc. The reason why you need to evaluate this stuff is that startups are really hard, and often take more time than you think they will – as a result, it’s important to understand peoples’ motivations to make sure it’s a good match from the beginning.

A couple of the things that are useful to evaluate:

• How do they see work fitting in their life? Does the style match? (Mornings vs late, hours, etc.)
• Level of process and improvisation – how are decisions made, how well are things spec’d and defined, etc.
• Mutual goals and motivations – money versus serving a goal versus learning versus others
• What stage of startups do they like? Seed, mid, later on? Why?
• Long-term goals – create a great lifestyle company, or try to go big?

I think questions like the above should get equal billing as testing for skillset – these are the kinds of things that impact long-term collaboration and performance as much as mastery of skillsets of knowledge.

Figuring out the alignment of these soft skills reminds me a lot of this great interview with John Doerr of Kleiner Perkins, where he discusses Missionaries versus Mercenaries – you can watch the video here. Ideally, you find people who really understand and believe in the mission of the company – and if you have really smart mercenaries in the team, it may work well for when things are going well, but there’ll be significant issues if there are any hiccups (which there are bound to be some).

As a side note, this is often a problem with hiring metrics-oriented people, because their passion and interests aren’t as much in the value that’s created through the product as much as figuring out how to make the metrics go up. This can create a very revenue-oriented mercenary culture that leads to weird company vision problems. I think the ideal scenario is to find people who have a passion for the particular product you’re bringing to market, and then training them to be metrics-oriented, versus taking people who love numbers/data/algos and trying to train them to love a particular product area.

Comments? Any lessons to share?
If so, please comment below – would love to hear from other early stage startups and their lessons in hiring the first 10 or so people.

Want more?
If you liked this post, please subscribe or follow me on Twitter. You can also find more essays here.