Be A Hero: Help Some Cheaters Win A Spelling Bee

826mi_logo

Ever since I came to Michigan for business school, I've been volunteering at 826michigan, the local chapter of the awesome 826 National organization.  It's very similar to 826 Valencia or 826 Chicago or your local 826 of choice, but we have a totally awesome robot store as our storefront.  We do tutoring, creative writing workshops, publishing, field trips, and a lot of other activities to support youth ages 8 to 18 all over southeast Michigan.  

Just like our big brother at 826 Valencia, 826michigan has a Spelling Bee For Cheaters.  And my team of two - me and a great friend, Ira Shaughnessy - intend on not just winning the thing, but blowing all previous fundraising records away.  And we need your help; please donate to our team at http://www.gifttool.com/athon/MyFundraisingPage?ID=1574&AID=1470&PID=183941

Writing is incredibly important to me.  As a child, I was a rabid devourer of books, magazines, and whatever else I could get my hands on - to the point where I'd stick my nose in a book in the middle of class, oblivious to my teachers and fellow students.  In high school, I had teachers who taught me the difference between storytelling and fine writing - learning that the content itself isn't enough, that the felicitous turn of a phrase can make all the difference.  In college, I had a professor who fundamentally changed the way I approached writing - Dr. Pat Hoy - who not only taught me how much thought and foresight goes into constructing a work of writing (Virginia Woolf didn't think in streams of consciousness; her essays were painstakingly constructed, with as few as 75-100 words a day surviving in her final manuscripts) and why a strong vocabulary is important, but how to use the act of writing itself to question my assumptions and mold my own thinking.  

Writing well is a skill that makes everything else you do better.  It makes you a better communicator, it makes you more observant of the world around you, and, unquestionably, it makes you a better thinker.  826's focus on helping young students find joy and confidence in their writing is near and dear to my heart and I'm proud to have the opportunity to help the students of southeastern Michigan find their voices.

But we need your help to fund these great programs.  I would be thrilled if you could join our fearless band of Honest Cheaters, Dirty Rotten Spellers, and Mustachioed Heroes in lending a helping hand.  Our goal is to raise $5,000, which would be the most ever raised by a single team in 826michigan history.  Also, it would put our team directly into the finals, where we could win a big honkin' trophy.  And, to the person who donates the most, I will send you a signed copy of whatever Dave Eggers work you want.  I don't have signed Dave Eggers works lying around, but he'll be at our little hootenanny, and I'll make sure he signs your choice.  Probably by knifepoint.

And, in the hopes that every little bit helps, I've changed my profile pictures on Twitter and Facebook to one with me proudly rocking a sweet (fake) 'stache.  Every time you see my mug holding up that mug of beer, I hope you're reminded of your kindness in donating or ashamed that you haven't yet. 

PCI Compliance In The Cloud: This Changes Everything

This-is-a-big-fucking-deal
Amazon announced today that they have PCI compliance certification for the entire AWS stack: EC2, S3, EBS, and VPC.  This is huge.  Almost every startup these days uses some cloud hosting provider, and until now, it's been literally impossible to be PCI compliant in the cloud.

To be PCI compliant, the website owner needs to be able to provide physical access to the servers in the event of a credit card breach.  If you're running in the cloud, you can't provide physical access to an auditor, since you have no way of gaining physical access yourself.

The merchant account providers don't know the first thing about hosting, and they don't really care.  And no startup I know has moved to bare metal and hired a sysadmin just to follow the letter of the standard.  Startups have better things to do than subject themselves to an audit by Trustwave or some other QSA that certifies PCI compliance.  (See, you thought you were PCI compliant, but you're not.)  But if some companies now magically have PCI compliant clouds, then they have every incentive to rat on their competitors who aren't to Visa/Mastercard, effectively shutting down their ability to process credit cards.

Given that this is a rather large deal, I've asked Amazon PR to send me a copy of the QSA report.  Just to prove to yourself that this is a big deal, look at the list of PCI compliant providers: http://usa.visa.com/download/merchants/cisp-list-of-pcidss-compliant-service-providers.pdf (PDF link)  Amazon is like that Sesame Street song: one of these things is not like the others.

One of things I want to figure out is if Engine Yard's EC2 instances are de facto included in the PCI compliance report, or if only customers contracting directly with Amazon are covered.  Hopefully, the QSA report answers this, but if not, I'll try to run this down with Amazon and Engine Yard.

Upshot: my best guess is that this raises the table stakes for every other cloud provider out there, and if you're in a competitive market and you're not on AWS, your competitors can attempt to report you for PCI violations.  You should ask your cloud provider when they'll provide PCI compliance, and if they can't give you a roadmap, you should investigate moving to Amazon.  

Ten Steps To Ten Thousand Sign Ups Before We Even Launch Our Startup

Blueleaf is building the world’s first truly personal financial planning platform.  It’s a complex product with a lot of features to meet all the different problems that our customer discovery has shown that people want.  Here are ten concrete things we’re doing to get 10,000 sign ups before we even launch our product.

1. Making Potential Users Ask Publicly To Get In

There are two ways to get into Blueleaf: get an invite from us, or get an invite from a current user.  We let in a limited number of users every week, and we choose who we let in based on how much they want in.  Only people who request an invite and follow us on Twitter, Like us on Facebook, or otherwise make it clear that they want in, get in.  This means they have to sign up with us and tell everyone else about us before they can get in.

2. The World’s Strictest Invite System

The other way to get in is to get referred in by a current user.  We’ve developed our own twist on refer-a-friend: rather than limit the number of invites someone has, there are an unlimited number of invites – but we’ve limited the time frames to invite a friend.  We turn on the ability to invite a friend for just an hour or two so that people who want in have to beg everyone they know who’s on to let them in before the window closes.  When we announce that invites are on, potential users need to plead for invites publicly on Twitter and Facebook, privately over IM and e-mail, or however else they can reach current users.  Again, this kicks off a viral loop before the app has even launched.

3. Splitting Up Blog And Library Content

We write – a lot.  We publish something new almost every day.  However, most of our new content isn’t on our blog – it’s in Blueleaf's library of articles about financial planning.  It makes no sense to hide an article about bond funds and bond ETFs on a blog, where it’ll be impossible to find in a month.  We’ve segregated our greenfield content so that someone looking for that topic five years after we publish it can find it easily.  Plus, we can easily update and change this content as laws, tax policy, and the investment environment changes without confusing new or returning visitors. 

4. Having A Strong Point Of View

When we write content, we rarely do six of one, half a dozen of the other.  When we write about Roth versus Traditional IRAs, we don’t do pros and cons.  We say that if you have to ask the question, you should open a Roth IRA.  The vast majority of Americans qualify for a Roth.  They should open a Roth.  For the people who should open a Traditional IRA, we go through the reasons when it would make sense – but we don’t do false equivalence.  On our opinionated articles, Blueleaf’s position is front and center, up front, before the rest of the content to deliver as much value as we can in as few seconds as possible. (BTW, we do absolutely no SEO analysis or keyword stuffing.  That stuff is lame.  We write answers to the questions people ask us, simple as that.)

5. We Don’t Blog About Our Product

The Blueleaf blog has three components: Blueleaf Stories, Blueleaf Thoughts, and (to come) Blueleaf Tech.  Our Stories are the Blueleaf staff writing about their own personal financial experiences so that we can make it clear that we’re making a product that we’re very emotionally invested in.  Over time, we’ll ask our users to contribute their own.  Blueleaf Thoughts are about things we find interesting that we think will also be interesting to our audience.  We want to provide value for everyone who is saving for their financial futures, regardless if they’re interested in our product right now or not.  If we have interesting stuff, we’ll get links and traffic.  That’s it.

6. Link Roundups For Users And Relationships

The other thing we do on our blog is post twenty links every Friday afternoon, comprised of the four handpicked links we tweet out each weekday.  Not everyone follows @blueleafcom on Twitter, so it’s a nice convenient place to have some leisurely reading over the weekend.  However, the real clever thing about link roundups is that they provide Trackbacks to the financial bloggers we want to establish relationships with.  Bloggers click through on their Trackbacks, see the Blueleaf site, and get interested in the product.  This makes it much easier to develop relationships and approach them for coverage as we get closer to launch.

7. Using Facebook And Twitter Very Differently

Instead of using our blog to announce new features, we use Facebook Notes.  Also, Facebook is the only place to get a feed of every new piece of content we post when we post it (there’s no RSS feed for our Article content).  Facebook is Blueleaf's broadcast medium for people who want to keep up-to-the-minute with what Blueleaf is up to.  We use Twitter to share interesting links and we’ll use it as a cornerstone of our customer service as we add additional users.  We’re so big on sharing links on Twitter that we have two accounts for it – @blueleafcom and @BlueleafLinks.  The only thing we do on both?  We’re diligent about responding to anyone who comments on Facebook or @replies to us on Twitter.  

8. A/B Testing The Hell Out Of Everything

We A/B test a lot – we’ve tested calls to action, button colors, button size, headlines, images, and a litany of other things using Visual Website Optimizer and Performable.  But we make sure we don’t end up in local maxima.  We’ve A/B tested radical redesigns of our homepage, and the current page is the one that beat the pants off our old one.  We do this A/B testing so that we can maximize our conversion, regardless if the traffic to our site is a trickle or a flood.  We’re ready to catch all the fish in the sea that just happen to be swimming by.

9. Being Smart About Paid User Acquisition

We’ve tested all sorts of various paid acquisition channels – everything from Google and Yahoo to reddit, Facebook, and directory sites.   We’ve been able to drive down our Customer Acquisition Cost (CAC) to a very reasonable amount – not the blended CAC between paid and free, but our CAC on paid alone is very, very attractive.  Even though I’m the guy who called AdWords “a gateway drug to unprofitable user acquisition”, being smart with small paid tests that get your CAC down to a reasonable number makes potential investors all hot and bothered.  Proof that you can get affordable paid acquisition makes fundraising much, much easier.

10. Knowing Just Who The Hell Is Signing Up

We run every single e-mail we get through Flowtown so we know a bit about who’s coming in through the open door.  Doing this, we can stagger who we let in when and we can have better content for our e-mail newsletters to those on the waiting list.  We reach out to people we’ve identified as potential influencers and we make sure that we don’t let people who are potential investors until the time is right.  (Join the club, folks – not even our current investors have access to Blueleaf.)  Letting in the right people at the right time means that we prime the pump to yield water only when we’re thirsty for new sign ups.

Be Careful About Outsourcing Your Customer Acquisition

Crossing-chasm

One of the great things about services like AdWords, Wufoo, Mailchimp, Flowtown, Performable, and so on is that they allow the marketing side of a startup to work independently of the engineering side of the startup.  Whip out your credit card and you can have a source of traffic, lead generation forms, e-mail marketing campaigns, social media insights, A/B testing of your landing page, and all that great stuff.

The problem with this is that as these tools have begun to play better together (thanks to the magic of Webhooks), your data becomes a bit more trapped inside each of these programs.  It can be hard to audit your data and even harder to integrate this data into your core application.  You end up going to each service independently to answer basic questions such as "when did this user give us their e-mail address?" and "just where did we get this e-mail address from?"  And if you want to answer more complex queries such as "just what is our overall (blended) customer acquisition cost (CAC)?", you have to export your data into CSVs and manually massage them together, which can be a very painful process indeed.

The bigger issue is when you try to integrate this information with your main app so you can do cohort analysis.  Cohort analysis is the magic analysis that tells you how you're doing on your key retention and engagement metrics over time: "did our June signups come back to the site more often than our April signups did?"  Trying to import user acquisition dates into your database of existing users (once you've sent them an invite to your app) is very time-consuming as you want to make sure that you don't break anything - there are a large number of edge cases you have to deal with: you'll have users who gave you their address more than once (for example), you'll have users that have changed their e-mail address inside the app from the one they gave you on your lead gen form, and you'll have users that have invited other users.

When you're a pre-launch or early startup, you don't have a lot of data points to deal with.  This is good because it means that you can, with effort, use Excel or some other tool to tie together all these different repositories of data.  But it's also bad because you may not think to have systems in place to more elegantly handle measuring your AARRR metrics post-launch.  You'll be so busy putting out fires and doing PR that you may end up neglecting instrumentation.  

While you may not have to do everything in-house, it's critical to have an engineer on your team who's involved in business/marketing support from time to time.  Defining and implementing an integration and migration paths (a lot of these services *do* have APIs for example, but those aren't something the mouthbreathing "business guys" can do anything with) before you launch is critical to make sure that you can calculate and measure the things you'll need to calculate and measure as you scale your business.

 

TechCrunch Disrupt Was *Awesome*

Techcrunch-disrupt-logo

I've worked a fair number of large events - Howard Dean's last rally in New Hampshire after Iowa before the primary, where I brought 1,400 people to Plymouth State University in the midst of a snowstorm and 20 below temperatures, the inaugural Personal Democracy Forum, and Major League Soccer's All-Star Game - and TechCrunch Disrupt has been the most well put-together large event I've ever had the pleasure to work on.  

The alternating between experts and "celebrities" and small, scrappy entrepreneurs is a masterstroke.  The venue - an abandoned Merrill Lynch office - is inspired.  And the energy - oh, the energy! - has been spectacular.  (And that's to say nothing of the free booze on Tuesday and Wednesday nights.)

I've had a blast working as a volunteer in my capacity as a rising MBA student at the University of Michigan and as the Director of Marketing at Blueleaf.com - I have never been more productive than I was here at TC Disrupt.  Kudos to Heather, Gené, Tanya, and all of the other people who helped to put together this inaugural event.  It had to be as spectacular as TechCrunch 50, but in a new city, in a new venue, with new personnel.  That's certainly no easy task.  And they more than rose to the challenge.

Lapsed Users - Your Most Valuable Untapped Resource

Tumbleweed

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

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

Paypal_versus_merchant_account

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

Michigan-ross-school-logo

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%

Drew-carey-price-is-right-beau


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:

Sachin-agarwal-consulting-rate

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-rates

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-rates

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:

Freshbooks-rates

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:

Basecamp-projects

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

Dont-be
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.


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.