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.

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%.

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 eBay, Kongregate, 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 Danc, Randy Farmer and Bryce Glass, Amy Jo Kim, Raph Koster, Jane 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 (@cindyalvarez) post, 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.

Product Development Starts With A Hypothesis, Not A List Of Requirements

For a startup to be successful, the founders (or whoever owns product) need to have strong opinions about both the market problem and the product solution.  Sometimes - maybe even often - this means ignoring your users.

That doesn't mean that you don't listen to your users - even companies as insular as Apple and Nintendo do some work reaching out to others.  Apple designs for others; they just don't do formal market research. Nintendo has "random employee kidnappings".  But if you don't have the luxury of having the singular, strong editorial voice that Apple gets from Steve Jobs or that Nintendo gets from Shigeru Miyamoto (or that 37signals gets from Jason Fried), you probably have to set yourself up to conduct lots of experiments.

Do you remember your scientific method?  If not, here's a really, really good primer on the scientific method.  Never mind that it's written for children - it's good.  Here are the steps:

Ask a Question
Do Background Research
Construct a Hypothesis
Test Your Hypothesis by Doing an Experiment
Analyze Your Data and Draw a Conclusion
Communicate Your Results

If you've noticed, we've actually done the first two steps.  Asking a question is finding a market you're interested in.  Doing the background research is figuring out the problem statement.  The next step, where we are now, is to construct a product hypothesis.  Remember, when you test hypotheses, they're falsifiable - you only can find out what *doesn't* work for sure.

What this means is that you have to keep pivoting until you find yourself in product/market balance.  Too bad that every product hypthosis and every pivot costs you in time, money, blood, sweat, tears, and all the other various inputs.  You can't iterate forever; you're going to run out of one of those inputs (most likely money).  

The only way to reduce your time in this cycle is to make a really good hypothesis from the get-go.  If you're not playing with other people's money, then you better make sure that you don't have to pivot at all.

Listen to your users on the problem statement - they can feel that pain.  But listen to your judgment on the first product hypothesis - there's a reason you want to solve this problem, and it's not because you're a stenographer.  It's because you see something everyone else doesn't.  Asking better questions allows to more clearly see what others - even your users - may not.  Here are some better questions to ask:
  • Are your customers time poor or just frustrated with the time they have to spend on a task?  
  • Are your customers cash poor or not seeing value for their money?  
  • Are your customers status poor or are they embarrassed to use your product?  
Customers often will tell you one answer, but they often mean another.  It's your job to 1) ask better questions, 2) read between the lines of the answers, and 3) use your judgment to make a really good product hypothesis.

Dropbox doesn't save a large amount of time; but it makes saving/retrieving files thoughtless.  RC Cola just didn't have the status of Coke (or Pepsi); you can always get store brand pop if cash is king.  

If you better understand the true pain, you'll make a better product hypothesis.  Dropbox is great because it "just works", but it took Drew to define what "just works" meant above and beyond Mozy, Carbonite, XDrive, and every other storage in the cloud provider.  RC Cola "tasted better" (they won every blind taste test they sponsored, supposedly), but it turned out that people didn't pick their pop based on taste.  They picked it based on status, nostalgia, inertia, (and as the supermarkets found out) price as a tiebreaker between Coke and Pepsi.  Remember, your users may lie to you.  

Users may not know what they want in a product until you show them.  But they always - always - know their problem.  

(That's what Steve Jobs is so damn good at.  He keeps using Apple's prototypes until the stabbing pain of the problem Apple's identified goes away.  Then and only then does he bless a new device/program/feature.  See copy/paste on the iPhone.)  

Your judgment on how to solve the (real, maybe unstated) problem of your potential customers is your initial competitive advantage.  Your ability to get a product hypothesis out there that your users don't immediately reject (and hopefully would be terribly disappointed if you took it away) is what gets you paid the big bucks (when you exit).

Because You Hate Your Family, or, Stuff To Read Over The Holidays


Let's face it - you love your family, but that's today, before you see them.  By Boxing Day, you're going to want to curl up in the fetal position as your uncle yammers on about the Cleveland Browns.  As long as you're hiding out in the basement, or drinking alone at the depressing corner bar, you might as well do something productive.  Here's a special "must read" list of books, blogs, and presentations while you stew about in the hellhole your parents call home.

Steve Blank - the granddaddy of them all.  Steve coined the term "customer development" as a parallel process to product development.  Steve's blog is fascinating (the man has done some very interesting stuff), but the must-read is his book, Four Steps to the Epiphany.  In particular, it specifically talks about how to work when you're disrupting an existing market versus when you're building a new market for your product.  You have to read Four Steps first.

Eric Ries - the new hotness.  Eric took Steve Blank's class, learned about customer development and had the insight to pair the customer development process with extreme programming to create a continuous improvement/feedback loop.  Eric coined this process "Lean Startup".  Eric's blog is great, but he has a MVP beta of his posts in an e-book, which may be easier to read.  You should buy it now, since Lulu might take a while to ship.

Dave McClure - the pirate.  Dave's AARRR model is the best compilation of every driver you need to measure.  You can't just slap on Google Analytics and think you're done, folks.  He's kind enough to post new versions of his Startup Metrics for Pirates presentation as he revises it (video of an older presentation), but Dave's blog (while a bit all over the place) is chock-full of great insights.

Sean Ellis - the Glengarry leads guy.  You've built it; now what?  Sean only works with companies that have raised venture money and already achieved product/market balance (see why I don't call it product/market fit).  You don't even have a product yet.  Why is he a must read?  Because his approach to measuring product/market balance is better than anyone else's.  His startup pyramid tells you each necessary step before you can turn on the growth spigot.  Sean's blog is updated less frequently, but every post is great.

Andrew Chen - the savant.  Andrew's spent a lot of time thinking about viral loops.  Virality isn't something that just happens to great products - although that does happen from time to time - virality is something that can be baked into your product's DNA.  Andrew's blog is full of posts that go into viral loops in detail, and it's much easier to read now that he made a special categorized list of posts for you.  You can't possibly read all of this before you come home, so I'll stop there.

Requirements Gathering Is Not Customer Development - But It Does Define The Problem Statement

Customer development is all about testing your hypotheses.  This is the Lean Startup diagram by Eric Ries that you (should have) seen before:

Let's start at the beginning and focus on the Customer Development Process, and in particular, the Customer Discovery loop at the very beginning:

Steve Blank has defined the Customer Discovery loop as four parts: Author creates Hypotheses; Author Tests Problem Hypothosis; Author Tests Product Hypothesis; and Verify, Iterate, and Expand (slide 11):  

The problem that I've seen time and again is that people fall in love with the process and get so caught up in the notion that they can just iterate through their hypotheses that they create terrible hypotheses.

This is dumb.

People - especially smart people - love the idealized notion of "iteration" but, in practice, it turns into "throw shit against the wall and see what sticks".  Then they realize the hypothesis testing iteration process takes time and soon, they start to believe they're making progress merely because time has progressed.  Then they start product development too early.  Then they... well, you can guess what happens from there.  Don't do that.  Spend just a bit more time up front.  Understand the problem you're solving first, so you can make better product hypotheses from the get-go.

Simplify the Customer Discovery loop into two parts: requirements gathering to define the problem statement, and hypothesis creation that you test with actual potential customers in the Customer Validation step.  Here's the difference between me and Steve: you don't iterate on the problem hypothesis - the problem statement is a fact that you have to suss out from your requirements gathering.  Your job is to suss out 1) whether or not there is a problem, 2) how big of a problem it is, and 3) how big the market is that's affected by the problem.  (You don't want to develop a product to solve a problem that won't return your investment of time and money.  This is the result of jumping into the "test product hypotheses" too early.)  These are all verifiable facts; the problem statement is not a hypothesis.  Anyone else going out to the same customer base and asking the same questions will come up with the same problem statement that you do.  

Defining a problem statement really isn't all that hard.  Sure, you can read research reports and get market sizes and all that jazz, but the one prerequisite you must do is really quite simple: talk to enough potential customers until you've reached some point of diminishing returns.  (You'll know it when you get there.)  Often, this doesn't take more than a dozen.  If you really want to be rigorous and pretend you've gotten to statistical significance, talk to 30 people.  Here's a simple list of questions:

* How do you do [x]?
* What's the worst thing about doing [x]?
* How much extra time/money/energy does it take to deal with the worst thing about [x]?
* If I could solve the worst thing about [x], how much money would you pay me?  (Note that if it costs money to deal with the worst thing about [x], theoretically you could charge up to 99.9999% of that amount.  Theoretically.)

Everything else is optional.  My trick is to keep them talking with one simple phrase: "that's really interesting.  Tell me more."  You may even (read: you will) get product insights from your problem statement questions.  

Eventually, you should be able to hone in on what exactly is the jabbing pain in your customers' eyes.  For salespeople, it was that they had to input all their information into ACT and then do extra work when they got to the office to share it with their manager (Salesforce.com).  For runners, it was that the shoes they had weren't really comfortable for running long distances (Nike).  

The iteration comes only with the product hypotheses - and I use the plural because you want to consider all the different product approaches that can solve the problem.

Let me finish with this: you don't define the Minimum Viable Product.  The market does.  At the beginning, your job is to form good product hypotheses that you test.  These product hypotheses spring forth from spending the time in requirements gathering to sharply define the problem statement that you are going to solve with whatever your product solution ends up being.  

If you've done the work to define a robust and accurate problem statement as a result of a rigorous requirements gathering process, you'll receive much better market feedback when testing your product hypotheses.  Eventually, when you start market testing your alpha product, you'll have a much shorter process getting those orders/eyeballs/whatever to determine you've hit your MVP.  

Next time, I'll talk about when to follow and when to ignore your customers when defining and testing your product hypotheses.