Lapsed Users - Your Most Valuable Untapped Resource

You're struggling with user acquisition.  No one's coming back.  Your product is robust and full-featured and you're adding new features every week.  You're only building the features that your users want, so you're not wasting any time on "wouldn't it be cool if" problems.  But no matter how hard you work, your graphs just aren't up and to the right. 

What to do?

One of the most valuable resources that startups (consumer web, again) have are the e-mail addresses of their registered but lapsed users.  It can be very valuable to reach out to them and figure out what part of your message or product didn't resonate.  Remember, if your "very disappointed" score is between 25% and 40%, it's often the message - and not the product - that isn't resonating.

Of course, if only 2 or 5% of your registered users remain engaged, it's probably both the product and the message. 

Here's a simple way to find out what's going on.  First, find a well-defined cohort of users.  This cohort could be from your last marketing push, or even "all users who signed up in winter" - you want they survey respondents to be as similar to each other as possible.  Grab the e-mail addresses for all of the ones who registered who fall out of your engaged metric (last 7 days, last 30 days, etc).  Send those lapsed users from that cohort the following e-mail:

Dear $user,

Thanks so much for signing up for $product!  We noticed that you haven't been back in a while, and we would love to know what we could do to make $product better for you.  If you click on the link below, we have a quick, two-minute, four-question survey that would really help us out:

$survey_link

If you fill out this survey, you'll get $free_product/be entered to win $free_product/have our undying gratitude.

Thanks so much!

$founder_1 and $founder_2

That's it.

The survey should have these four questions:
  • Why did you sign up for $product?
  • What did you think you were getting with $product?
  • How did $product disappoint you?
  • What can we do to make $product better for you?

These are, of course, unstructured questions, so you're going to have to read all the answers.  Don't worry about missing stuff - the patterns will be repeated over and over again so you won't be able to forget about them.

If you want, you can add a checkmark box or a field to capture phone number for follow ups.  Make sure that you don't ask for name or force respondents to leave any personal information if they don't want to.  You want them to give their unvarnished feedback.

Take their feedback - figure out if it's the product or the messaging that's falling short.  If it's the product, add those features (and think about killing the ones they're not using).  If it's messaging, that's even easier to fix.

Introduction To Online Payments - TL;DR: It's A Total Bitch

Online payments are a bitch.  Just over a decade ago, you had to hook up your online commerce system to an actual terminal that would send bleeps and bloops to the gateways, but even today, it's not much better.  There are still a plethora of players who have to touch your information to process a simple credit card transaction, and each and every one of them gets to take a little bit of your money and introduce their own technical hassles.  While there are never any easy answers - every option has pretty severe tradeoffs - I'm going to try to shed some light on how the process works and look at some of the major players/options you have for accepting payments on your website.

The traditional way to process online payments is to have an internet merchant account, and talk to that account via a payments gateway.  Nowadays, many internet merchant accounts come bundled with a gateway as part of the cost (notably, Authorize.net), but they are separate and you can always choose to use the gateway of your choice (as long as they work with a processor platform that's supported by the merchant account).

"Wait, what?" you say.  "You said you were going to shed some light, but you're just confusing me with all this talk about accounts, gateways, and processors."  Well, I told you that online payments were a bitch.

OK, let's start at the top.  An internet merchant account is what you need to accept credit cards on your site.  Despite its name as an "account", it's really not an account at all.  An internet merchant account merely gives you permission to accept credit cards.  At the end of every day, the internet merchant account will deposit all of your funds into your real checking account that you maintain with your bank.  So think of an internet merchant account as a holding pen of sorts.

The vast majority of business banks (Bank of America, Silicon Valley Bank, etc.) can provide you with an internet merchant account, but you will rarely want to go that route.  While the costs are often higher, the real reason you don't want to go that route is that you're more likely than not to be denied a merchant account as these banks (SVB, Square 1, etc excepted) are more used to traditional brick-and-mortar merchants and you can often spend weeks or months applying for an internet merchant account just to be turned down for being "too risky".  If you just Google "internet merchant accounts", you'll see a bunch of companies who are dying to give you their business.  

Personally, I highly recommend TransFS to find an internet merchant account.  All of the merchant accounts on TransFS are "interchange plus" accounts.  Interchange is the fee that Visa and MasterCard charge to process their cards; these fees vary depending on the type of card - consumer versus business, plain vanilla versus rewards, and so on.  (The complexity and fees are actually a big enough deal that there are advocates to reform interchange in Congress.)  Interchange-plus passes along these charges plus an incremental amount; in almost all cases, interchange plus is both cheaper and more transparent than "qualified/non-qualified" bundled rates.  While the bundled rates may be simpler, they're often mischaracterized in a way to benefit the merchant account provider at the expense of the merchant. (If you want to learn more, read this post on TransFS' very comprehensive blog.)  These merchant accounts will generally charge you a "statement fee", aka "the fee you pay us monthly for the privilege of being a customer" plus a small percentage (usually between 0.15% and 0.30%) and a flat per-transaction fee (usually 10-15 cents).  I have worked with a merchant account provider called CoCard that I found via TransFS and have generally been very happy with their customer service and fees. 

It will take you about three to four weeks to jump through all the hoops to acquire the internet merchant account, so you need to plan ahead to have a merchant account ready to go before any launch.

Once you have an internet merchant account (or while you're going through the process), you need to find a gateway.  Again, you write your code to talk to the gateway; the gateway takes the credit card information that users input on your site and talk to the processors (First Data, Paymentech, Global Payments, etc.) to get the funds released to the merchant account (which then sweeps into your regular bank account).  Most internet merchant accounts will resell or bundle a gateway - most often, it's Authorize.net.  Auth.net (for short) is a perfectly serviceable gateway for most use cases, but if you need a more elegant gateway API, you may want to pay extra for Braintree's payment gateway.  Braintree has focused on e-commerce since their founding and they (while not perfect, especially with their documentation) are generally considered the easiest gateway to work with.  However, if you decide that you want to use Braintree's gateway with your internet merchant account, you need to make sure that your merchant account supports the First Data Nashville processor.  (There's actually a First Data Omaha processing network which does not work with Braintree.  Why?  I have no idea.)  Braintree's gateway will add significant costs to every transaction, but you're paying for a more elegant API and premium customer support.  If you're doing large dollar ticket sizes, these additional fees may be worth it; if you're doing lots of small dollar amounts, they may not be.  (And forget about it for microtransactions.  Use PayPal or Amazon Payments' specialized solutions for microtransactions.  I'd recommend PayPal as it's easier to grow into their other offerings as necessary.)

Well, that's a lot of work.  Why not just use PayPal?

Actually, that's a very good question.  While many people may have poor experiences with PayPal, they are invariably easier to get set up and understand than the combination of hoops and charges for an internet merchant account and gateway.  In addition, PayPal can often be cheaper.  Here's a pretty little chart that PayPal has on their site:

Let's be clear; this isn't to scale, but it does accurately display the differences in complexity.  (One note - if you use interchange-plus pricing, you're not subject to the downgrade fees that kick in for qualified versus non-qualified transactions.)  What's confusing about PayPal is that they have three products that you can use: Website Payments Standard, Website Payments Pro, and PayFlow Pro.  PayFlow Pro is a standard gateway that works with any internet merchant account (PayPal actually acquired this line of business from VeriSign back in late 2005).  Website Payments Standard and Pro are combined merchant accounts and gateways.  The main difference between the two is that with Standard, the transaction happens on PayPal's servers.  With Pro, it happens on your servers.  In addition, with Standard, you have to accept PayPal as a payment mechanism; with Pro, you can accept credit cards only.  (Why you would want to comes to how PayPal funds their accounts; e-checks don't clear for three to five days and introduce risk to merchants that credit cards, with their instant money transfers, do not.)

In some cases, PayPal can be cheaper than the combination of merchant account and gateway.  In particular, if you have very high tickets (average order sizes) and a mix that is skewed towards business cards (which have higher interchange fees), PayPal can often be more economical.  PayPal's simplified rate structure is a marketing tactic that, on balance, does make PayPal more expensive than the more complex option.  EDIT: You can compare PayPal versus a standard merchant account with the PayPal Upgrade Calculator built by TransFS.  (Disclosure: I worked with TransFS to build this calculator, a relationship that happened after this article blew up.)

However, there is one additional downside to PayPal: they will oftentimes hold back up to 25% of your proceeds for three months as a fraud prevention/risk management effort. This means if you charge a customer $100, you will only get $75 immediately and will have to wait three months to see the $25 balance.  If cash is tight, or you are running inventory, this can kill your business.  

There is one additional issue to consider when deciding on your merchant account, gateway, PayPal, and your options: vendor lock-in.  In most cases, you are locked into a particular vendor.  This is because they store the credit card information on your behalf (unless you use a standard merchant account and decide to try to be PCI compliant - which is a whole 'nother ball of wax that requires audits and precludes using cloud hosting for your e-commerce).  In particular, if you have a subscription recurring billing model, this vendor lock in can be killer because you can't switch providers without forcing your customers to return and re-enter their credit card information in a very limited timeframe between your switch and the next billing cycle.  To avoid this, there are a small number of vendors who provide "vaults" that store credit card information in a portable manner.  

The two most well-known vaults are Authorize.net's CIM and Braintree's vault.  A newer company focused on their elegant subscription payment API, Recurly, also provides a vault (but they are not a gateway provider themselves).  These companies offer credit card portability if you ever choose to store credit card data yourself.  (You may be able to move from one vault to another, but I'm not sure if this is actually possible.)  These vaults are the only way I know of to offload PCI compliance while still maintaining some flexibility in changing merchant account or gateway vendors.

OK, so here's the million dollar question: so what should you do?

As far as I'm concerned, there are three real options:
  • PayPal Website Payments Pro
  • Braintree Gateway + Account
  • Authorize.net + Merchant Account (add Auth.net's CIM, Braintree's vault, or Recurly if you need vendor flexibility)
PayPal will be the easiest to get set up, by far, but the 25% holdback can be a killer.  Braintree's single-source solution will take longer to set up, and will be the most expensive option for most cases, but they provide the most flexibility and best customer support.  Getting your own merchant account and using the bundled gateway will presumably be the cheapest option, but will invariably cause you the most headaches.  You can avoid some headaches by writing to Braintree or Recurly, but then you will lose much of your cost savings, but you'll retain the flexibility to host the card numbers yourself or possibly switch vault providers.  

Of course, if you don't mind having the checkout transaction happen on someone else's servers, PayPal, Amazon Payments, and Google Checkout are all (non-exclusive) options.  Here's a good rundown of all three.

I recognize this is both a very long and completely uncomprehensive review of online payment processing.  As I've repeatedly said, online payments are a bitch.  I intend on revisiting and editing this post as comments and additional information becomes available. 

Why This Startup Guy Is Going Back To Business School


Today is my last day as Operations Lead at oneforty.  In the fall, I'll be headed to the Ross School of Business at the University of Michigan to pursue my MBA.  
 
Because I've been asked a bunch of questions about this, I figured it might be fun for others to see (and critique!) my thinking.
 
Why business school?

Amongst startup folks, MBAs get a bad rap. Some smart people don't even want to interview MBAs.  But it turns out that a lot of companies won't interview you without one.  I literally have an e-mail in my Inbox from a recruiter at a very prestigious company that is one of the largest traditional recruiters of MBA students who loves my experience, but can't hire me without a graduate degree.  While we can debate the pros and cons of the company's position, it does mean I'm precluded from even considering a position with this firm until I have my MBA.
 
An MBA isn't a substitute for startup experience and drive, but it doesn't preclude it either.  From my perspective, it's easier to go to school full time and work on startups part time (both mine, and helping others) than working at a startup full time and trying to swing a part-time MBA.  My read is this: getting an MBA has the highest option value out of the things I could do with myself at this point in my career.
 
Besides, there's precedent - if Tristan can pull it off at Foursquare and Stanford, then I can certainly pull it off as a part-time consultant while I'm at school.
 
Why Ross/Michigan?
 
Out of the top ten business schools, Michigan was easily the best fit for me.  The environment at Ross is very different than some other schools; Rossers are driven, but not competitive.  They have fun without being self-indulgent.  They're friendly without weird forced group hugs (thanks, John, for unwittingly providing me that dig at your alma mater).  The new building is the best learning facility I've ever seen.  And I couldn't be more excited about having a chance to watch the first night game ever at the Big House.  I hate Notre Dame.
 
Of course, professionally, it's a slam dunk.  Every single company that traditionally recruits MBAs that I would want to work for recruits on campus at Ross.  If I want to go the strategy consulting route, I can do that.  If I want to join a large technology company in a product management or product marketing role, I can do that.  If I want to get hands-on experience with consumer marketing at a CPG company, I can do that.  And, yes, if I want to join or found a startup, I can still do that.
 
In addition, Michigan has more top-ten graduate programs than almost any other school in the country.  This means that I can complement my formal business school education with classes from the law, engineering, and other schools on campus.  For example, you know how the Lean Startup movement has strong roots in the Lean Manufacturing processes pioneered by Toyota?  The guy who wrote the books on Toyota's processes is a professor at Michigan.  If there's ever been an opportunity to do a formal academic dive on the base assumptions underlying lean startups, this is my best chance to do so.  I don't need to wait for someone to modify an existing class to incorporate Lean Startup principles; I can write a few chapters of the damn textbook myself.
 
Why now?

I'm 29, which puts me at the upper edge of your traditional full-time MBA student.  I didn't feel comfortable putting off school, if I was going to go at all, any longer.  Being older also means I have a number of friends who have already finished B school.  Talking to them, one of the most frequent pieces of advice was to take the summer "off", so I decided to do so as well, now that oneforty closed its Series A round, launched e-commerce, and moved to its more permanent offices in Central Square.  The Company is in a great position, and I can take the summer to learn Ruby on Rails, travel a bunch, and make the most of an opportunity to do interesting things before I take on new obligations.
 
What now?
 
I'll be taking a desk as an Advisor at TechStars here in Cambridge for the next month (thanks Shawn), helping out the startups there with product, marketing, positioning, pricing, and other questions/issues.  In addition to the 2010 Boston TechStars companies, I'll also be helping out at a small handful of more established startups in town.  I'll also be blogging more regularly, and tweeting some more as well.
 
I want to close this out by offering my thanks to Mike, Michael, Robby, Yifei, Jamie, and Jason for being awesome to work with.  I also want to especially thank Laura for letting me come out from Chicago, run the Series A process (from first meeting to close in 37 days - beat that with a stick), do customer development, user testing, marketing, and own point on a myriad of other tasks as well as letting me leverage her insane, awesome network for my own personal benefit.  You really should consider joining the team.
 

Setting Pricing for a Startup - The Rule of 80%


In just the last week, two different people have come to me to get feedback on their pricing. One was a startup selling a very sophisticated product to corporate enterprises. The other was selling consulting services to individuals, small businesses, and trade associations. In both cases, however, the questions were the same: how should I price this on a per-head basis? When should I charge a flat fee? How do I make sure I'm not leaving money on the table? How do I make sure I'm not losing customers?

First thing I said was: you need to have a public rate table. I believe that people like to comparison shop, but that they only choose amongst those providers who make it easy to compare prices. If you provide a rate up front, you are at a substantial competitive advantage to your competitors who require potential customers to fill in a lead generation form. Second, if you have a premium product and you have a competitive advantage because you make it easier for customers to compare you against the competition, for the love of God, raise your rates. Higher costs are a signaling mechanism that you're selling a premium product. I can't find a link, but there's an apocryphal tale that Cadillac sales actually went down in the 1980s when Cadillac lowered prices. Traditional economics says that lower prices means you move right on the demand curve, leading to higher sales, but it didn't happen because consumers thought the lower prices were a signal of lower quality.

OK, now that we'd established better base rates, the question came down to how do we set the appropriate levels based on demand? Surely you want to have quantity discounts, especially for those parts of the business that are easily scalable. Well, to start, let's take a look at a business I know intimately well.

Here are my rates for business consulting and GMAT tutoring services (two wildly divergent services, one simple rate table):

Hours Per Hour
1-4 $150.00
5-9 $125.00
10 or more $100.00

As you can see, there's a substantial price break for pre-paying for more hours. This allows me to better manage my schedule and worry less about new client recruitment, and it encourages my clients to buy more hours as they get more "bang for their buck". It's a traditional win-win situation.

(Note: I've actually since raised my rates since this was originally published in November 2009: they're now $300, $250, and $200 an hour for the various pre-payments.  Read on for why.)
How did I pick my rates? Well, they just "feel" right. It "feels like" a good balance of encouraging larger purchases, but there's no real rhyme or reason. To me, it's like the golden ratio: it just "feels" right. However, it also turns out that there's a constant that shows up again and again in other successful companies' pricing. Let me demonstrate with pretty pictures:

Here's a graph of my consulting/tutoring rates:

As you can see, there are two steps: one at 5 hours and one at 10 hours. Everything else is constant. As you can see, at the 5 hour mark, my new rate is 83% of the rate for 1-4 hours. At the 10 hour mark, the new rate is 80% of the 5-9 hour rate. So the reduction in rates is very similar: about 80% of the prior rate.

Well, remember how I said we see this in lots of other places? It's really quite uncanny. Let's start with everyone's "it just works" darling, Dropbox:

Dropbox has a free account up to 2 GB, then paid accounts that go up to 50 GB and 100 GB based on payment. As you can see, the price per GB spikes once you need just a little more than 50 GB, but then it comes down to the levels from 30-50 GB. It turns out that you pay exactly the same amount per GB at 80 GB as you do at 30 GB ($3.00/GB per year) and exactly the same amount at 100 GB as you do at 50 GB ($2.40/GB per year).

Here's the graph for 37signals' Basecamp:

Basecamp comes in four paid flavors: 3 GB of storage for $24 a month, 10 GB of storage for $49 a month, 20 GB for $99 per, and 50 GB for $149 per. Again, you see the same spikes in yearly price per GB at the break points. Again, as you get into larger amounts, the difference for every marginal GB becomes relatively minor. Again, it's a bit asymptotic at the tail (in this case, in the mid-$30s per GB per year).

Lastly, let's take a look at Freshbooks:

Unlike the others, Freshbooks charges per client, not per GB, which makes sense as it's an accounting system, not a file storage repository. Freshbook charges $19 a month for up to 25 clients, $29 for up to 100, and $39 for up to 500. In this graph, I don't go all the way out to the "Starship" and "Time Machine" packages (seriously, guys, WTF?), but you can see the same spikes in per client costs at the 25, 100, and 500 client breakpoints that we saw for the GB breakpoints for Dropbox and Basecamp.

"But wait!" you say. "These graphs show spikes in the per-unit costs only at the break points - they're almost flat at the other points The graph for your consulting services showed troughs in the break points." This is true, grasshopper. Except! Take a look at the first few data points for all three. Notice something? At the small amounts, there actually is a substantial difference at each incremental GB or client (the lighter line). Let's look at these differences in table form:

Dropbox

GB Price Per GB % of Previous
0

1

2

3 $39.96
4 $29.97 75%
5 $23.98 80%
6 $19.98 83%
7 $17.13 86%
8 $14.99 88%
9 $13.32 89%
10 $11.99 90%

Basecamp
GB Price Per GB % of Previous
0

1 $288.00
2 $144.00 50%
3 $96.00 67%
4 $147.00 153%
5 $117.60 80%
6 $98.00 83%
7 $84.00 86%
8 $73.50 88%
9 $65.33 89%
10 $58.80 90%

Freshbooks
Clients Price Per Client % of Previous
0

1

2

3

4 $57.00
5 $45.60 80%
6 $38.00 83%
7 $32.57 86%
8 $28.50 88%
9 $25.33 89%
10 $22.80 90%

That's right - early on, there's a lot of 80-something percents in the per-unit differences.

So here's my rule: The rule of 80%.

For anyone selling on an incremental basis, set your break points that the per-unit costs of the new tier are 80% of the per-unit cost for the previous tier. If you're a consultant, whatever your break points are, charge 80% on a per-hour basis at your breaks. If you charge $1000 an hour, whatever your break point is - 5 hours, 10 hours, 1000 hours, make sure the per-hour charge after the break point is no more than $800 an hour. If you sell beer at $5 a bottle, make sure the cost of a six pack (the logical break point) is no more than $24, for a per-unit cost of $4.

If you're selling at a fixed price, it's a no more complex. You just must make sure that your break point from your first paid tier to your second paid tier is high enough to clear the 80s on the light line and it gets into the 90 percent range. If you set your second paid tier too early, before the dramatic savings in per-unit use peter out, your customers will be able to "feel" that you're trying to rip them off and they may not sign up with you in the first place. Once you give them enough goodies at the first paid tier, then you can feel free to ratchet things up - just make sure that your third and fourth tier ratchets don't kick in until the per-unit cost is at or below the limits of the previous tier. (Essentially, make sure your dark line is at the low point in the graph before you create a new tier.)

Well, based on this rule, it looks like 37signals is ripping users off on their Plus plan when compared to their Basic plan. Perhaps that's why they highlight the Plus plan - to avoid comparisons to the Basic plan in favor of comparisons to their Premium and Max plans, where the Plus plan does look like a fair deal. Or, perhaps, maybe the per-GB comparison is the wrong one. So let's take a look at the per-project comparison:


Well, shiver me timbers, but that looks just like the other graphs in the series: same severe downslope with humps in the dark line, same gentle curve with spikes in the lighter line, but no spikes until you hit the 90's.

Now, of course, I'd recommend that 37signals bumps up storage on their Basic plan, with the attendant bumps down the line, but hey, that's just me and my Rule of 80%.

Presentation: Don't Be a Douche - Best Practices For Game Mechanics In Your Web App

Here's my presentation from BarCamp Boston 5 on Sunday, April 18, 2010.  It doesn't work as well without me jumping around, questioning the audience, berating their answers, and generally acting like a, well, douche.

http://www.slideshare.net/sachinag/game-mechanics-best-practices-bar-camp-boston-5

Because most of the deck is very text-light, here's an overview of the general structure of the presentation:
  • First, for fun, I introduce Irwin R. Schyster as our Chief Revenue Officer character and The Million Dollar Man, Ted DeBiase, as the founder/philosopher king character.
  • I review the differences between game mechanics and viral mechanics because I've found that people often just think "FarmVille!  Zynga!  Wall posts!  Game mechanics!" and I need to disabuse them of that notion.
  • First "ah ha": viral mechanics lead to additional revenue by reducing customer acquisition costs and game mechanics lead to additional revenue by getting engaged users to pay for things that make engagement more fun/easier.
  • Based on what I've read, I talk about how 2% of users upgrade from free to premium in freemium apps (Freemium Summit) and 2% of game players purchase additional content (MIT Business in Gaming conference).  Just putting it out there as an observation, not a hard and fast rule.
  • Then there's a basic overview of three different types of karma trappings, and how points lead to completion lead to achievements.
  • Second "ah ha": using Foursquare as an example, I talk about how viral mechanics have more utility to the sponsor/company than to the user, whereas with game mechanics, all of the utility accrues to the gamer/user.
  • Jumping off of Jesse Schell's 2010 DICE talk, I introduce two hypotheticals - Twitter and Etherpad - on how existing web apps could use game mechanics to incentivize and reward "good behavior".
  • Third "ah ha": I talk about how if web app makers use game mechanics to incent good behavior, they could also use the same scaffolding to monetize additional features on a one-by-one basis through microtransactions. (My favorite tweet from this section of the presentation.)
  • Lastly, I wrap up with two text-heavy slides that bring together and revisit the core themes and learnings from the presentation.  (Those of you who know such things will see a lot of David Sirlin in my recommendations.)
Because this is a work in progress, I've chosen not to (yet) make full notes available or the deck available for download.  (Also, it's a sneaky bleg to get people to invite me to give the speech again.)

I'll be in the comment section to answer questions and take abuse.

 

Good Game Mechanics In Your Web App Are Good For Your Users

  

There are two things I know more about than you: marketplace dynamics(1a,1b) and game mechanics(2).  I was planning on doing the marketplace one first, but there's a little blogging bubble about the pros and cons of game mechanics, so I might as well strike while the iron's hot.  

Let's start off with some background reading.  Wikipedia's entry on game mechanics is as good as any, and in particular for web startups, Yahoo!'s Reputation Patterns overview is a must-read.

Done?  Good.

When most people talk about game mechanics in web applications, they generally are talking about one of two things: karma (which rewards quality engagement, see eBayKongregate, or Reddit) and virality (which comes from incentivizing user-to-user referrals, see FarmVille or any other Zynga game).

The stuff in Yahoo's Reputation Patterns are various methods of scoring and presenting karma; these things are neutral-to-good for users.  Social proof has utility; the value of the utility differs from user-to-user.  (Most people play Xbox 360 games for the fun of the games themselves; some, however, are achievement whores who will play numerous terrible games just to increase their Gamerscore.)  These Reputation Patterns show the myriad ways that applications can reward and display good behavior - they're all just different methods of displaying social proof, what I call "the trappings of karma".  The general objection to game mechanics is usually about these trappings, in that they obscure "more important" things - the main game/app itself or, extended out, real life.  While I understand these objections, they aren't sufficiently convincing - these objections tend to come from situations where the game/app/experience itself is poorly designed, making the external mechanics more attractive on a relative basis.  If you don't like achievements, points, and badges, you're free to ignore them.

The rewards for making referrals to others - as you see in Zynga games, most notably - are designed to benefit the game creator/website operator/the company/whatever more than the user herself.  Any benefit to the user, while it may be large, is less than the benefit that accrues to the corporate entity sponsoring the game: i.e., Zynga designs their rewards precisely so that the company gets more benefit from a user referring a new user to a game than the user herself gets for the referral.  As you can imagine, I'm a bit less enamored of these sorts of referral game mechanics than I am game mechanics that reward users directly.  These sorts of referral incentives feel the same as AdWords arbitrage to me - they can be tremendously lucrative, but must be carefully managed and actively tweaked at all times; there's no "set it and forget it".  Ideally, the product itself is so good that users start signing your praises - sneezing - without any formal incentive structure; examples of this are Dropbox, Google, and Mint.com.  I'm more interested in making products better; at the very least, great products don't have to be monitored 24/7 and I enjoy my sleep.  :)

Also note that the notion of rewarding virality is different than products that have increased utility as the number of people using them increases, notably social networks like Facebook and Twitter.  (I leave out eBay here for reasons that I'll get to when I do the marketplace dynamics post.  It's fallacy #1 and the fallacy makes me physically angry.)

The reason people get excited about game mechanics in web apps is that they're directly tied to two of the five things in  Dave McClure's AARRR framework  - retention (as a result of increased engagement spurred by the quest for karma) and referral (virality from incentives).  Retention is great because it increases pageviews (which gets you more ad impressions if you're monetizing via advertising) and referral is great because it reduces your customer acquisition cost (remember, your LTV/CAC ratio needs to be greater than three or four to account for fixed costs.  If you can reduce your CAC, you're on your way to making a dimes-into-dollars machine).

However, these are the easy things to do with game mechanics.  I'm much more interested in game mechanics that make a product inherently better so that you have natural sneezers.  Users who talk about and promote your product because the product is so damn good are the best kind of users to have; they're much more valuable than incentivized users, because you can only throw so many incentives at users before you've exhausted them.  

So what are the game mechanics that make a product inherently better?  How can you use game mechanics to get true sneezers?

The first example of game mechanics that make a product better are interactive tutorials that make it easier for users to understand and use your product.  The most notable of these is Microsoft's Ribbon Hero.  Ribbon Hero on-boards new users to Office 12, making them more productive within the Office Suite even after they have stopped playing the Ribbon Hero game.  If users want, they can share and compare their scores with others, but that's not the key mechanic.  The increased productivity is the end-goal and the immediate reward.  Productive users of Office 12 are much more likely to be effective sneezers than users who are motivated by incentivized referrals from the game.

The second example of game mechanics that make a product better are those mechanics that increase an individual's utility as they add additional information to the site.  This particularly works for applications that are built upon collections - applications like Delicious, Mint, and Google Reader have increased utility to the user as the user adds bookmarks, accounts, and RSS feeds, respectively.  Game mechanics that reward users for engaging in these actions - actions that they should be doing anyway since they're already users of the app - benefit users directly without the need for the trappings of karma.  (None of these applications, by the way, use game mechanics anywhere near as much as they should.  In Delicious' case, in particular, it's a crying shame.)

At oneforty, I spend a lot of time thinking about how we can use game mechanics to have a better inherent experience for our users.  Most new visitors to oneforty aren't even aware that there are such things as "Twitter tools" or "Twitter apps".  These visitors might be familiar with a Twitter app on their iPhone or Blackberry, or maybe even a desktop client, but they're completely unaware of the hashtag monitoring tools, networking apps to find new people to follow, or entertainment sites that show off people's funny tweets (among 2,500 other Twitter tools and apps).  Well-designed game mechanics that help educate and expose our users to the best Twitter applications and tools for what they don't even know that they're interested in is a true win-win for users and for the Company: they're mechanics that will create natural sneezers rather than incentivized referrals.

Please note that you can't just bolt on game mechanics onto an existing application or experience; if you do, you're much more likely to end up rewarding behavior that you don't want - you'll end up with users gaming the system to the detriment of other users.  This is what happened with Digg's Leaderboard, for instance - they ended up having to kill it because a small subset of users were more motivated by their rank than by the rewards they received from natural interaction with the site, resulting in a "less good" experience for all other users of the site.

There are probably other ways that game mechanics can make web applications better that I haven't even considered - but retention, referral, education, and engagement should be more than enough to convince you that you need game mechanics in your app.  If you're still not convinced of the utility of game mechanics for your web applications, go read the interviews that Josh Porter has done with Amy Jo Kim and Bryce Glass.  If you want to leave money on the table, fine by me.  Makes my job to beat you in the marketplace that much easier.

(1a) Especially if you study auction theory for a living.  You think eBay proves you right about everything.  You're wrong for many reasons.  To start, see (1b).
(1b) For all values of "you" that are not Scot Wingo
(2) For all values of "you" that are not DancRandy Farmer and Bryce GlassAmy Jo Kim, Raph KosterJane McGonigal, Jesse Schell, or David Sirlin.

 

The Evolution Of The Customer Development Interview

Back when I did my very first customer development interviews, way back in 2007 for an aborted Slacker-player-over-cellular-networks company, they were called "requirements gathering".  Go out, get a big list of requirements, write a product spec, release, and bask in your glory.  Pretty simple.  

Needless to say, my approach and techniques since those halycon days has changed a lot.  Now I believe that users have no idea about solutions; they only know about their problems.  

Inspired by Cindy Alvarez's (@cindyalvarezpost, here's a real-world list of questions I recently asked a number of potential oneforty users and my thinking behind each question:

1) How/why do you use Twitter? (Make sure to push on business/personal use to understand both)
2) Tell me more about what you think Twitter is (For others in your industry / average users).
3) How has your use of Twitter evolved?  Are there any particular things about Twitter that suck?
4) Do you use any tools for Twitter or other social networks?  (Note that I don't ask where they find Twitter tools; I don't want to assume that they go looking at all.) 
5) What sorts of Twitter tools would be so useful that you'd be willing to pay personal money for?  (The personal use question - do they *really* want/need Twitter tools?  Consider it a pre-emptive "how disappointed" Sean Ellis question.  If the answer is "none", it's the equivalent of a less than 40% "very disappointed" response.)
6) What sorts of tools would you be willing to spend your employer's money on?  What is your budget?  Do you need a Purchase Order or approval above a certain threshold?  (Pricing discovery to gather lower stakes information about willingness to pay - with OPM.)

One of the things that you'll note is that there are only six questions.  These are the six questions I want to get answers to; they don't have to come in this order, but I want to try to get to them.  They serve as jumping off points for each stage of the interview, not the next step.  If the interviewee goes off on a tangent, it is my job to follow her there.  I can cut her off if and only if we're running short on time.  If time's not a worry, exhaust the tangent, then and only then move on to the next kickoff question.

With these kickoff questions, I start as far back as I can so I don't assume that the problem I'm trying to solve is actually a problem for my user base.  Even if I've done previous interviews and come to a pretty firm problem statement, I always start from the beginning to try to get the user to come to that same problem statement organically.  If the user doesn't come to that statement, I abort the script and dive into the problem.  

I also never, ever suggest or test potential solutions during customer development interviews.  Once upon a time, I did.  I would suggest a number of potential solutions to my interviewees and ask them to rate or rank them.  Turns out they always chose the solution I secretly liked the best.  What a coincidence, that.  It almost convinced me that I could skip the whole discovery process because my market research (read: Googling) was so good.  

Maybe I'm not as good as others who conduct these sessions, but I had a hard time shielding my biases when talking about solutions with interviewees.  Users don't know what solution is best until they actually use it - they only know their problems.  So I stopped polling potential solutions and now I rely on interaction data and metrics by actual users of the actual product or MVP. 

Again, my magic phrase in every customer development interview is "that's interesting - tell me more."  (Note: this also works great on dates.)  Also, I never ask a yes/no question, I let pregnant pauses hang in the air until they're almost awkward, and sometimes I'll even willfully mischaracterize a interviewee's opinion to elicit their response - all in hopes of getting the interviewees to keep talking so I can get every last insight from the brief 30-60 minutes I have with them.

Hopefully, seeing a real, live customer development script used by a real startup with real potential users has been useful.  Fire away in the comments if you have any questions, concerns, or suggestions on possible new approaches.

On Incorporation - I Still Say Hold Off Until You Have The Cash To Spare

In my last post about startup cash management, smart people like Chris Dixon, Manu Kumar, George Grellas, and the Hacker News cabal all disagreed with my advice to put off incorporation until you absolutely have to. 

Every single benefit of incorporation cited by these people is correct.  However, I still caution against jumping right into incorporating from day one.  This is because when you incorporate, you should do it right and doing it right isn't a drop in the bucket.  Also, when you incorporate, you're subject to your state and federal taxes, Delaware franchise tax, foreign business license in the state where you're headquartered, and other administrivia hassles.  But keeping in line with the last post, I'll stick to the cash.

When I founded Dawdle, I engaged a local Chicago law firm that was well-regarded in the startup community to do a simple incorporation.  It ran us about $1,500.  I didn't want to use LegalZoom to do the simple incorporation because I wanted to develop a relationship with my lawyer that I could leverage to make introductions to local potential investors when the time was right.  

However, soon after incorporation, I realized we needed an option plan for a potential employee we were recruiting.  Because my lawyer had set us up as a subchapter-S Corporation, he was unfamiliar with how an option plan should be structured for an S-Corp and ended up having to do substantial research to get it done.  The option plan ended up costing us an additional $6,000.  There are additional pieces of advice that we got that was incorrect, the sum total of which ended up costing the company over $40,000 in additional, unnecessary legal expenses (hindsight is 20/20).

Based on this experience, I strongly believe that any company that may potentially seek institutional money should use a top-tier Silicon Valley partner at a top firm.  It doesn't matter where your company is; get a Valley partner.  Many of these top tier firms have "off the shelf" packages that include much more than incorporation - some include the option plan, convertible note template, NDA form, and other commonly used documents.  You can see a sample of the bare minimum set of incorporation documents at TheFunded.  If you hold off on incorporating yourself and you get into a top-tier accelerator such as YCombinator or TechStars, they will also incorporate the company, with the whole kit and kaboodle, for you.  YC even tells potential applicants to not incorporate "if you can avoid it".  You probably can avoid it.

If you aren't going the accelerator route, and you've decided the time is right to incorporate, you'll need to get a full incorporation package from one of these firms.  This package runs approximately $5,000 or so from a top-tier firm.  (Feel free to let me know if this has gone up since the last time I checked.)  Generally, a paralegal will just fill in the blanks and the partner you choose will do a cursory glance, but the partner is 1) the person who can answer your questions without any research, saving you money and 2) the person who will be making introductions to potential investors.  It's important to pick your partner carefully.  Thankfully, my ex-Broadview colleague Giff Constable has a great list of lawyers that do good work with internet startups.  If you want specific thoughts on how to pick a startup lawyer, read Mark Suster's post on the topic (even though he's in the "incorporate yesterday" camp, it's still a great post).  

My personal recommendation for startup incorporation and general corporate work is Yokum Taku of Wilson Sonsini.  In addition to being wicked smart and a straight shooter, Yokum's blog, Startup Company Lawyer, probably already answers the first five questions on the tip of your tongue.  Past that, any answer to something you can't find on the blog is going to be consistent with what he's already written, saving you from conflicting advice.  You can read my rambling notes from my conversation with Yokum about incorporation at my personal blog.

I also don't believe that you should take advantage of deferred legal fee loan programs offered by some Valley firms because you're locked into working with that firm until you've closed your Series A.  If the partner leaves, the firm overbills against the deferred fee loan amount (usually $25,000), or the relationship doesn't work out for some other reason, you don't want to be stuck.

Because "doing incorporation right" is a rather large expense, I don't believe that entrepreneurs should incorporate until they are playing with other people's money.  Solo entrepreneurs need to watch every dime and I firmly believe that small founding teams can set the parameters on a napkin when starting out, to be codified when the time demands it.  If you can't trust your co-founders to stick to a terms written on a napkin, you've got bigger problems to tackle.  Sure, all else being equal, you do want to incorporate as soon as you can to start the capital gains clock, minimize the value of founder shares, and all the other benefits or early incorporation.  But $5,000 is still $5,000 and cash is king.

 

Three Things To Put Off As Long As Possible For Your Startup

While there are often investments that should be made upfront, oftentimes new founders and new startups will waste money and time on things that they shouldn't.  I sure know I did during my first go-round.  Don't make my mistakes.  Here are three things you should put off as long as possible:

Don't incorporate until you're playing with Other People's Money.

There are two kinds of other people's money.  The first is Other People's Money - investment dollars from outside sources: friends, family, angels, VCs, certain grants, and so forth.  The second kind of other people's money is even more important - paying customers.  Any concern about your personal liability is misplaced; if your site has a bunch of Google AdSense ads, no one in their right mind is going to sue you.  You're going to need to be incorporated to deposit any investment (if you're so lucky) and you'll need to be incorporated to get an internet merchant account.  You can probably get by with a PayPal account (under the domain of the site; don't use your personal PayPal account) for a while, as well.  And don't worry about the intellectual property you create before incorporation; you can always assign it to the company later.  That's what Google did when they got their first check before they were even incorporated.  

Don't do any paid user acquisition until you can calculate your CAC and LTV.

It's very, very tempting to "experiment" and "test" various paid customer acquisition channels.  You start with AdWords, then do some cheapo banner ads on a couple of ad networks, and soon you're hooked on some hard affiliate stuff and paying thousands of dollars a month to an Outsourced Program Manager.  AdWords are a gateway drug to unprofitable user acquisition.  Only start throwing your dimes at paid acquisition when you're damn well sure your dimes-into-dollars machine is humming nicely.  And you only really know it's humming nicely until you have enough metrics around your unit economics - what your costs are to serve every new customer, and how much she's worth to you in revenue (if you're rigorous, gross profit).  These numbers have to come from real users using your real product; they cannot come from a financial model - that's just guessing.  Get hard data.  Then and only then can you think about customer acquisition channels that have direct costs above zero.  Until then, you're much better off engaging in inbound marketing - making remarkable content (you blog regularly, right?) and a remarkable product - and really thinking about your on-site SEO.  

Don't hire a PR agency, part-time sales force, or any other outside consultant.

You want to be focused on the product.  You get the market well from your industry background and you know you have your problem statement nailed from your in-depth customer development interviews.  You need to focus on building your product solution hypothesis and you just can't be bothered to do the legwork of developing relationships with bloggers, press, potential customers that you don't know, or potential business development partners.  You met some smooth business guy at some tech meetup who says he can do all this for you for a small amount of cash and equity.  Seems like a good deal, but it's not.  Managing someone who isn't a full-time employee and who isn't as invested in the company's success as you are is a path towards hurt feelings and wasted time, energy, and cash.  There are certainly times and places for help in all these matters, but pre-launch isn't it.  (The only exception is if you've raised millions of dollars in Other People's Money and you can afford to pivot your product, positioning, and or price if your big splash fails.)  You probably won't be as good as someone whose work life is dedicated to press, PR, sales, marketing, or whatever - but you're going to be a lot cheaper and you may not be all that bad at it yourself.  A passionate and articulate founder can go a long way - I was able to do all of this myself, getting into TechCrunch, landing new customers from cold-calling, and striking business development deals.  You can too.

The Other Stuff That's Not Product That You Need To Build Early

One of the things that I didn't think about before I started my first startup were all the parts of the infrastructure that weren't product.  They've also consistently been the things that other entrepreneurs forget about when they come to me with their "ohmygodIhavethisidea" ideas.  They're also vitally important because they allow the founding team to actually execute the pivots you'll need to execute quickly, intelligently, and without sacrificing development of the actual product that you're trying to pivot.

The first part of this infrastructure is the admin panel.  This admin panel is what will allow you to do troubleshoot for customer support, engage in administrative actions, and audit your payments in and out of your system without having to mess around with your production database.  I cannot impress upon the first-time web entrepreneur just how important it is to have a robust and well-functioning administration system.  When you're building your administration system, it is important to make sure that you can disable and delete users, view and change payment regimes, and reset user passwords (because they will invariably not be able to find your reset password form and they *will* e-mail you).  If your product takes off and you find yourself bringing on board a business person, they're going to be tasked with support, and you do not want whoever is doing support interrupting engineering to complete basic Level 1 and 2 customer support.  If your product really takes off, you may find yourself bringing on board a dedicated support person.  If you wait until traction to build out your administration panel, you're going to be ceding ground to the competitors that spring up when they see your traction.  Django's admin panel is so well developed that you may not have to build your own, and is a reason to strongly consider the framework if you're familiar with (or interested in) Python.  Even as your product pivots, the administrative support tasks generally don't.  

Make sure you've built a functional admin panel before you launch.

The second part of the infrastructure you're going to want to build (or implement with WordPress, Melody, or some simple bare-bones CMS plugin that someone has already released for your framework) is a content management system (CMS).  It should not take a push of new code to change the static content on your website.  Holding up basic changes and updates to your about section, marketing pages, terms of service, privacy policy, and help section because you need to wait on some guy to merge his branch into master (or check into trunk, or whatever your VCS calls it) is silly.  You don't want to have your marketing person or intern create some hot new copy then have to hand it off to engineering to copy/paste it into code and markup each and every link, line break, and image to get it live on the site.  It makes the business side frustrated with the pace of changes and the engineering side of the house gets frustrated at having to do such menial tasks when they could be building some crazy awesome technology that is your core long-term competitive advantage that you brought them on board to do.  Again, some web frameworks have bare-bones CMSs or templating engines built into the system out of the box.

Make sure you've built (or implemented) a content management system before you launch.

The third part of the infrastructure you need to build is a good metrics dashboard and logger.  The standard piece of advice is "pick a few metrics, but log everything".  The idea of logging everything when you've decided to focus on just a few Key Performance Indicators (KPIs) can often cause heartburn.  But it's relatively simple; build a separate table (or database) that automatically logs all the various things that users do.  Don't worry about duplicating writes that you're doing elsewhere in your database.  Having a separate table (or better, database) will save ou on reads and JOINs and whatever else when you need to dig in.  The one thing the logger needs to do is be *auditable* - that is, you need to be able to say that user_id=8273 did x on page one, then y on page two, then z on page three.  These loggers are so important that there are venture-backed startups that exist solely to help other startups collect these logs and make sense of the data they're collecting.  The KPIs are, of course, actionable metrics that exist in the aggregate, but the ability to see what any individual user has done will help you troubleshoot, audit, and make hypotheses for new features and functions.  Also, one quick note: Google Analytics aren't auditable at the user level nor actionable in helping you make forward-looking hypotheses.  Everything in Google Analytics is backwards looking.  The product is free as in beer and all-but-free from an engineering cost perspective, which is great.  GA does give you the ability to find exception cases and the basic funnel visualizations can be useful for getting conversion metrics up and running quickly, but don't kid yourself - Google Analytics is mostly data porn.  

Make sure you build a real metrics dashboard and implement a real logger before you launch.