I wrote this post a year ago but it was too painful to share until now. Hope you learn some of these lessons the easy way.

—

My biz partner Dan and I shut down EasyCal last week after three years of work and meagre earnings (we never grew beyond $200/m). EasyCal was an online booking calendar for solo practitioners – massage therapists, hair stylists, etc who worked for themselves. In the end, it wasn’t a hard decision – not only had it become a burden to run, but it was costing us money.

Here are the key lessons we learned:

1. The market wasn’t good enough

Solo practitioners (SPs) are often cheap and unsophisticated business people (and I mean that in the kindest possible way). Even though these folks would charge e.g. $100 for an hour long massage, they didn’t think about the time they spent booking appointments the same way. We had one plan – $19 / month – which could save them hours per month, but many of them balked at the price.

Digging in the couch cushions for nickels ain’t a great way to build a big business (unless your customers are spending someone else’s money).

Being a solo practitioner is often a flexible business. SPs will quit working for a few months, join a salon or practice that already has a booking system, go traveling for a few months, etc. So we’d have customers use the product for a few months, then churn out when their situation changed.

You’ve probably noticed that this boils down to differentiating properly in order to sell to the right customers. Mind Body Online and others are building huge businesses off of selling to multi-practitioner clinics, but doing the same selling to solo practitioners is a lot harder.

2. We built before understanding out customers

I talked to a 5-6 potential customers before we started building the product – far too few. I didn’t learn what their key problems were with booking, or more broadly with running their businesses. We didn’t find a big enough group of customers who were scheduling appointments the same way (and thus had the same type of painful problems) for whom our solution would be first best. We didn’t find out how to reach them.

Consequently, we spent too much time – over a year – building an average product for a too-broadly defined set of customers.

Nobody loves you for being the fifth best solution to their problem.

3. The product wasn’t differentiated enough

Our working hypothesis – which we validated the hard way – was that online booking software was too complicated for the needs of the solo practitioner. The key player at the time was Mind Body Online, which has a great sales force, but at the time (2009) had a gross product. They’ve come a long way with their product as other players like Genbook have jumped into the market.

MBO had a plan for solo practitioners, but the product experience was overly complex for people who didn’t need the bells and whistles associated with running a multi-stylist salon. So we decided to build a better mousetrap for people who didn’t need those bells and whistles. Turns out that we didn’t do a good enough job differentiating from the MBOs of the world, or any of the litany of both small and large players in the very crowded online booking market.

4. We weren’t passionate about the customers

We lost motivation as we realized that we didn’t care about the problems that most of these SPs had. When we realized that the way we were solving online booking wasn’t that important to our customers, we didn’t care about changing the problem we were solving to a higher value problem because we didn’t care enough our this set of customers.

Since we didn’t care enough about our customers, we frankly didn’t deserve to succeed.

5. We weren’t passionate about the problem

We weren’t super passionate about solving the problem of online booking. If we were, we could have tried other verticals (e.g. scheduling phone calls between busy professionals), or expanded to include clinics with a different spin (e.g. mobile first). But we didn’t have the intrinsic motivation to make EasyCal succeed, and so changing direction was daunting.

6. We had no framework for discovering a reliable acquisition channel

We tried four tactics to get customers:

1. a free trial postcard in a goodie bag at a massage therapists conference
2. landing pages that targeted long-tail terms like “massage therapist online booking calendar”
3. small business blogging about running a solo hair stylist business, massage therapy practice, etc
4. running a few AdWords ads (a.k.a. “lighting money on fire”)

We never found a tactic that worked (the landing pages were the best, quickly rising to the top of SERPs – a Patrick Mackenzie trick). But worse, we didn’t develop or use a framework to help us find a tactic that would work, scalably and repeatably.

Gabe Weinberg’s Bullseye framework is the place I generally start today though it wasn’t around at the time. Both my co-founder and I were new to marketing, and we never took the time to apply systems thinking to marketing.

Lesson learned: spray and pray marketing without a framework will rarely make you successful.

7. We got caught in the trough of sorrow

Traction cures a lot of problems, at least for a little while. We never got out of the trough of sorrow, and the emotional toll it takes was exhausting. It’s hard to buoy your co-founder when you’re both down in the dumps, doing lots of work but not reaping any rewards. And when your drive to help your customers or solve the broad problem isn’t there, AND you’ve got no traction, you’ve got a recipe for quitting.

8. We spent too much, too soon on legal expenses

We spent over $5k on incorporation and a bullet proof shareholder agreement with a corporate lawyer. Though we had worked together before and liked and trusted each other, this was the first business we started together so we wanted things to be airtight. It was a waste of money to spend so much before we knew whether the business was a real business or a startup idea.

If you don’t trust your co-founder you’ve got bigger problems – legal docs don’t build trust.

The next business I started – SocialWOD – I borrowed an idea from my friend Eric at BeerMenus and signed a “Human Agreement”. A Human Agreement spells out the high level terms of the partnership (equity split, etc) and assumes your partner won’t be a douche. When it became clear we had something with SocialWOD, we incorporated and used the Human Agreement terms as the basis for our shareholder agreement. Much smarter to delay spending until we were making more than we spent to incorporate.

But with EasyCal, we lit more money on fire on an iron-clad shareholder agreement that was effectively useless. This wasn’t a cause of failure per se, but it hurt to spend cash on something with so little return.

—

I’ve found it to be true that lessons learned are all the more painful when you learn them the hard way. Here’s hoping some of these lessons come to mind when you’re figuring out how to grow your business.

I was chowing down a bacon hot dog and perusing Hacker News over lunch when a comment caught my eye.

Patio11, otherwise known as Patrick Mackenize, mentioned he’d written an email course for WP Engine.

Patrick being one of my unofficial mentors (he doesn’t know it, but I learn something from pretty much all of the stuff he writes about engineering and marketing), I hopped on over to WPEngine and signed on up for the email course, both because I was in the market for WordPress hosting, but also because I wanted to deconstruct what Patrick had done.

Here were my two key takeaways:

First, the “email-course” (e-course) technique is a powerful sales tool.

Second, dripped emails like an e-course (called “dripped” because they’re sent at set intervals automatically) can make you a lot of money. Note: I use “e-course” and “dripped emails” interchangeably in this post, but an “e-course” is, of course, a way to use dripped emails.

Read on to learn how they did for me.

How the WP Engine E-Course Worked

The WP Engine course was offered as an add-on to getting a “speed test” of your WordPress site.

I received 8 emails “dripped” out to me automatically over the course of a month. Here is the subject of each:

1. Results of your Speed Test
2. Why Hosting Matters
3. Backups, Maintenance, Migrations
4. Keeping your site and users safe
5. Making sure your site doesn’t go down when it gets popular
6. Saving money on hosting
7. Two quick wins for improving your site’s performance
8. More WordPress resources (this is the closer)

Each email:
– describes a benefit that hosting with WP Engine offers
– explains why it’s important to you and/or your business, and
– mentions that, oh, in case you want to pay a small amount of money every month to get these benefits and have it handled by the credible experts who taught you why the benefit is important, the good folks at WP Engine will gladly take your credit card info

Why a course works

A course is a fantastic sales and marketing tool. It frames selling your product in the guise of education, letting you teach your prospect why your product’s benefits are important, addressing pre-sales objections, make an ROI case, and helping your prospect envision how much better life would be with your product.

The brilliant part of this approach is that they were primarily teaching me why managed Wordpess hosting was worth paying for, while demonstrating credibility about their expertise. And I knew a sales pitch was coming – WP Engine is in the business of making money – but because they provided so much value for me, I was fine with it (turns out I was very receptive, since the blog you are reading is hosted on WP Engine).

My pal Noah told me that in the early days, he wanted people to feel guilty *not* buying from AppSumo because they gave away so much valuable stuff for free.

Ramit Sethi does the same – his info products are expensive, but he gives away tons for free (taking advantage of the Reciprocity principle – if you’re selling anything online and haven’t read Cialdini’s Influence, go buy it now – it’ll change your life. But I digress.)

Dripped email courses work especially well for products that don’t have a super short sales cycle (i.e. B2B or B2C purchases with non-trivial pre-sales signup friction). Educating these prospects about how your product or service improves their lives often takes time and effort. And since prospects have demonstrated interest in what you have to offer, dripping out a set of emails is a great way to turn that demonstrated interest into dollars (indeed – short of the prospect returning and taking the time to learn about your product – emailing them is the *only* way to turn that interest into dollars).

How we used an email course at SocialWOD

At SocialWOD, we followed the same approach I deconstructed from the WP Engine emails. When someone joins our email list (to get a free ebook), we send him or her six emails over the course of three weeks. Here are the subjects of each email we send:

1. Building your gym’s community will build your business
2. Recognizing your athletes when they hit personal bests will keep them coming back
3. Call your athletes when they don’t show up to keep churn low
4. Using Facebook for word-of-mouth marketing is a powerful way to grow
5. Help your athletes set and reach their fitness goals and they’ll love you
6. More resources for your gym + close

Here’s what the open and click rates look like for each email:

Email #	Open rate	Click rate (of all recipients)	Click rate (of openers)
1	49.1%	2.9%	5.8%
2	47.2%	2.8%	6%
3	51.8%	1.9%	3.8%
4	50.4%	4.3%	8.6%
5	50.6%	5.7%	11.2%
6	52.2%	13.4%	25.2%

Notice that clickthroughs go up as we build credibility and give away value for free.

And while click-throughs are nice, revenue is nicer. I can write unequivocally that our e-course is directly responsible for tens of thousands of dollars in annual revenue.

And that’s in a tiny market of 4000 potential customers.

FWIW, these are unoptimized emails – we “set and forget” them a few months back. There’s definitely room for improvement, but for a marketing experiment, we’re pretty happy with the results.

Why you should use drip email marketing

The reasons why you should use drip emails are many. You:
1. Get to build a permission marketing relationship with a prospect
2. Demonstrate credibility and expertise
3. Teach your prospect about the benefits of your product in general, and why they’re valuable
5. Get to pitch prospects on why they should buy from you
6. Actually make money when they do

In terms of bang for our buck, drip email marketing really moved the dial for us. It took a couple days to write the emails, and a couple hours to set up the Mailchimp autoresponders.

Toss in a couple of free ebooks that your prospects are interested enough in to trade their email address for, and you’ve got a great formula for making money.

—
Update: in a funny coincidence, I just noticed Patrick launched a course on lifecycle email marketing today. Go check it out (not an affiliate link). I’ll be buying it shortly.

Are you a product manager or founder?

Take 30 seconds and think about the things that are wrong with your product.

Don’t worry, I’ll wait.

Ready? Go!

…

I bet you came up with a big ol’ list. I know I can.

Did your list include any of the following?

– fixing typos
– improving images
– tweaking css
– adding links
– removing links
– changing CTA colors
– fixing an edge-case bug that a customer wrote you about
– tweaking the logo

(If not, you win!)

My list included some of those things.

But here’s the thing:

Working on those things before you find a set of scalable and repeatable tactics to acquire and keep customers is a waste of time.

(And it’s usually a waste of time after, too).

Last summer, my friend Noah pounded the concept of high-leverage activities into my thick skull.

In other words, is what you’re working right now on really going to move the dial?

Here are some examples of things that move the dial:

– knowing why customers are churning, so you build a feature to keep them from churning
– having a hypothesis about how to acquire new customers, and testing new tactics to do so
– building new tech to reduce operational costs and improve customer happiness
– calling 10 new customers to understand what they like and don’t like about your product, and to understand why they signed up
– calling 10 free trial users to try and convert them to customers

Each of the above could have a significant impact on your business than, say, adding a link to your footer almost certainly won’t.

In the past I’ve found it hard to stay focused on the big things.

Still do.

Why you want to work on the small stuff

First, mentally holding the braying feature requests at bay is exhausting. It’s the little voice in the back of your head, the constant nagging reminder about needing to change copy, fix the logo, improving the spacing around tour images, etc. It would be so much easier if you took a few minutes to fix up this teensy tiny thing and get a hit of seratonin, wouldn’t it?

Second, working on the product is controllable and comfortable. The boundaries around people-problems (positioning, acquisition and retention) are unknown and often complex. You don’t necessarily know when you’ve gotten closer to the solution, and feedback often takes days, weeks, or months.

Code, on the other hand, is knowable and neat. You quickly know when you’ve solved a problem, and you get to play God in your development environment.

And if there’s one thing we humans like, it’s control.

Third, fixing problems is satisfying. When you check items off your list and your site gets “better”, you’re making progress, right?

Not necessarily.

It’s like answering 100 emails – it’s possible that you would have made more progress by answering the 1 email that is a game changer vs the 100 meaningless ones.

Again, high-leverage. Where can you spend your time to have the largest impact?

How I keep the dogs at bay

I’ve noticed that when I’m able to focus on stuff that moves the dial, I see more success in my business. (This skill becomes second nature to good product managers. Disciplined focus and prioritization are key.)

One hack I’ve found to be useful is to set my weekly priorities at the beginning of the week, and my daily ones each morning when I first open my laptop (before I check email).

I keep these in Evernote.

It looks like this:

Week:
– goal 1
– goal 2
– goal 3

Monday
– Task 1
– Task 2
– Task 3

Tuesday
– Task 1
– Task 2
– Task 3

On Monday, I cut and paste Monday’s tasks to a separate document so I can refer to them quickly without being distracted by the rest of the week.

The daily list helps me focus on what’s important and keeps me from being interrupt-driven. Whenever I’m wasting time when I should be working, I refer back to the list and start plugging away on the next task.

I allocate time to do interrupt-driven tasks and either:
a) deal with it ASAP (usually tasks that sales or customer-service related), or
b) put it on the list for consideration for next week

The last thing I intend is for this post to become productivity porn – the point is not that you should use my “system”.

But I know that learning the following was a hard-won lesson for me, and thought I’d share:

1. realizing that you can have a huge impact if you focus on the big things instead of the little things
2. it’s sometimes difficult to move the dial because of all the nagging little things you are tempted to work on, so
3. exploring ways to keep yourself focused and motivated will have a large payoff

I was stressing.

We had seen 40% of our customers cancel, and it was eating me up inside.

Each of those (former) customers had:

1. decided they had the problem SocialWOD solves (workout tracking for every gym member at your gym, just by snapping and emailing a photo of your results whiteboard)
2. decided they needed to solve that problem
3. done research on solutions that might solve their problem
4. decided that SocialWOD was compelling enough to try
5. decided to take out their credit card to pay SocialWOD
6. used and promoted SocialWOD to their members

After investing that much mental and emotional energy, they then they decided to cancel.

Argh.

We were trying to understand what the key differences were between our customers that cancelled, and our customers that didn’t.

We hop on the phone every week or two to call up customers, so qualitative data was no problem.

But we wanted to see what we could learn from our data.

Enter the Cohort Analysis

A cohort analysis helps you see how behavior varies across different cohorts of customers.

In this case, we were interested in the behavior of the cohort of customers who HAD cancelled, vs the behavior of those that hadn’t. What differences were there in each cohort’s usage of our product, and could we steer more gyms to do things like those gyms that had stayed on as customers?

I had read high-level stuff about cohort analyses, but it was this 90 minute cohort analysis class in NY with genius marketer Cassie Lancellotti-Young that really opened my eyes to how to run a proper one.

What Tools to use

Cassie recommended using Excel, and provided a template to use as the basis for a cohort analysis.

She mentioned tools like Kissmetrics and Mixpanel, but they were harder to use, less flexible, and required more overhead than Excel.

Given that likely all of the useful data you’ll want to analyze lives in your application’s database, her suggestion made a ton of sense to me.

How to start

We started by asking questions.

In this case, we were trying to answer this question:

“What are the major differences between customers that cancel, and customers that don’t?”

Pull some data

The next step was to write a ginormous SQL query pulling out all the data that could possibly help us answer this question.

Here’s some of the relevant data we pulled:

• The month a customer joined in
• The amount a customer paid per month
• Free trial length
• The number of a gym’s members that claimed their SocialWOD profiles
• # days after paying before canceling their service
• whether a gym uses SocialWOD to post their workouts to their gym’s Facebook page (where the gym’s members hang out)

All in all, there were 51 different fields of data that we pulled.

Analyze the raw data

I ran pivot tables comparing the difference between gyms that cancelled and gyms that didn’t.

I learned that customers who cancelled:

1. had about half as many of their members claim a SocialWOD profile (so they could engage with our product)
2. used the “post our workout results to my gym’s Facebook page” feature about half as much as gyms who remained customers
3. paid about 23% more than gyms who stayed
4. cancelled their subscription after 61 days on average

Square the quantitative with the qualitative

We have a spreadsheet that details cancellation reasons for every customer, and I’d estimate we’ve talked to at least half of the customers who quit.

The two most common reasons we kept hearing about why gyms quit were:

1. our athletes aren’t using it
2. it’s too expensive. SocialWOD is a nice-to-have (we’re working on that 😉 ). A member CRM is essentially a must-have for a gym over a certain size. The price for a member CRM is lower that it should be imho, and it sets a strong price anchor in the mind of a customer (i.e. “I *need* a CRM and it costs $X. I don’t *need* SocialWOD, but it costs $1.5X.”)

Given that the quantitative data suggested high member usage and lower price were big drivers of customer retention, the qualitative and quantitative data told a pretty strong story about what to do to cut down on cancellations.

Acting on the results

Here’s what we decided to do about each learning:

1. A cancelled customer had about half as many of their members claim a SocialWOD profile (so they could engage with our product).

Previously, our customers would tell their members to sign up for SocialWOD by posting an announcement about SocialWOD on their gym’s Facebook page, writing on their gym’s blog (read by most members), talking about SocialWOD at the gym, etc.

We figured there’s nothing easier to act on than an email describing benefits and a call-to-action. So we improved our onboarding to help a gym owner export a CSV of their members’ email addresses to send to us.

Once they do, we email each member a description of how SocialWOD benefits them, along with a link to click to sign up.

2. A cancelled customer used the “post our workout results to my gym’s Facebook page” feature about half as much as gyms who remained customers.

We improved our onboarding so that customers who haven’t set up posting to Facebook receive an email detailing the benefits, providing a video, and a strong CTA to do so.

3. A cancelled customer paid about 23% more than gyms who stayed

We built some technology than makes processing photos cheaper for larger gyms, and passed those savings on to both our existing and new customers. Those changes enabled us to drop prices by 15-60%, depending on price plan.

4. A customer cancelled their subscription after 61 days on average

We haven’t acted on this yet, but I can imagine sending gyms that meet some “likely to cancel” criteria an offer around day 45 of their membership to lock in for a year at a heavy discount.

The Outcome

Since implementing changes 1-3 two months ago, we’ve seen our cancellation rate drop from 40% to 5% – an 87.5% decrease. We’re going to run another cohort analysis in a couple months to isolate the impact of each change as it’s still too early to know the long-term impact of these changes, but in the short-term both Ryan and I are stoked about stopping the hemorrhaging.

—

Interested in learning how a cohort analysis can help your business grow? Get in touch – I work with select clients to help identify growth and retention opportunities, and build features to realize those opportunities.

—

Update (9/2/2012): You can now learn how to do a cohort analysis in this downloadable class.

Who this is for: a hacker with an idea.

Why you should read this: to figure out how much money your idea will make you.

—

The entrepreneur walked me through his mobile app – it was a cool idea, and I’d probably use it.

“How will you make money,” I asked.

“We’ll run ads,” he said.

“What are the CPMs like for this audience? How many users will you need before you hit break even?”

“Um, we haven’t looked at those numbers. But once we hit 1M users it won’t be challenging to make money.”

I see this all the time, and it stings. Probably because far too many times I’ve said the exact same words, only to find out after the blood and sweat of launch that I probably wouldn’t make enough money to be worth it.

“Dude,” I said, “if I were you I’d spend a couple hours in Excel and figure out exactly how many users you need to break even, and ballpark how much money you’ll make when you reach 1M users. Is it 10k a month? 50k? 500k?”

Our coffee date wrapped up, and he went on his way. I hoped he wouldn’t make the same mistakes I had in the past.

—

This step is the absolute first sniff-test you should do to figure out whether you’ll make money if you’re successful.

Excel is about as sexy as a pig wearing a miniskirt, so even I skipped this step in this series of posts on starting a venture. You can save a lot of time and frustration by NOT SKIPPING THIS STEP.

Put another way, there’s a high probability you will be making the same really stupid and avoidable mistake I’ve made (several times) if you don’t do this before you write code.

Don’t waste your life by designing and launching (multiple) app(s) without understanding how and whether the effort of launching will be worth it.

Will your app be profitable?

You want to figure out:

1. how many poential customers there are in your market
2. what your costs are
3. your ballpark price (and thus your gross margins)

Some of these numbers will be hard to nail down as facts; that’s OK – more facts will emerge as you talk to customers. The point of this exercise is to get an answer that helps you decide whether to explore the problem in more depth.

Let’s take a crack at it

I was talking to a couple people who wanted to start a grocery-delivery business. The wrinkle was that they would be delivering exact quantities of raw ingredients along with recipes to customers, so the customers could make meals at their homes.

Regardless of whether people would want this service, let’s take a quick look at the numbers to see whether this is even an idea worth exploring.

I’m going to make some assumptions that are probably wildly inaccurate for the purposes of this blog post. Given that you are actually working on a real business idea, I assume you would be much more thorough.

How many poential customers are there in your market

According to Wikipedia, there are 600k customer in Vancouver (where my friends wanted to start the biz).

Assuming the population follows a bell-curve distribution (25% young, 25% old, 50% just right), let’s say 50% of people are potential customers.

That’s 300k people.

Your costs

My friends wanted to start out buying food from Whole Foods and re-apportioning ingredients into appropriate packages for delivery. Scaling up would involve going direct to food distributors.

So, let’s say you can pay someone $10/h to grocery shop for 10 customers an hour. (I’m ballparking this, but you could test this assumption by going shopping for 10 customers yourself.)

And let’s say re-apportioning and packaging raw ingredients into deliverable meals can be done at the same rate.

And with smart software, delivery can be done at the same rate.

And let’s say you’ve got a set of recipes that will keep your raw ingredients costs to $10 max per customer.

That means your costs per meal delivered are $13, comprised of $10 in raw ingredients and $1 for shopping, $1 for packaging, and $1 for delivery.

You’d also likely have other costs related to cost of good sold – packaging, storing raw ingredients, spoilage, waste – and overhead like salaries, offices, customer acquisition costs, etc. But let’s keep it simple for this post.

Ballpark your price

OK, you’ve got a max cost of $13 per meal delivered. Let’s say you want to charge per meal delivered.

We can calculate your potential price based on a desired gross margin:

Price = Cost / (1 – desired margin)

Based on a $13 cost, here’s a table of margins and prices you could charge per delivered meal:

Gross Margin	Price	Profit
30%	$18.57	$5.57
35%	$20	$7
40%	$21.67	$8.67
50%	$26	$13
60%	$32.50	$19.50

The higher gross margin, the more profit for you.

You’d also want to model out alternate business models. What would it look like if you charged a subscription? Could you do this on an ad-supported basis? Etc.

So, how much will you make?

Assume you could reach each of the 300k customers in your market (this is obviously the best case scenario).

A conservative rule of thumb is 1% conversion from potential customer to paying customer.

So you’d have 300,000 * .01 = 3000 customers.

Assume each customer buys one meal a week.

Here’s what your gross profit would look like given the range of prices you might charge:

Gross Margin	Profit per customer	Gross profit per week
30%	$5.57	$16,710 ($5.57 profit per customer * 3000 customers)
35%	$7	$21,000
40%	$8.67	$26,010
50%	$13	$39,000
60%	$19.50	$58,500

Not a bad little business. Of course, this is a perfect world scenario – you’d likely never reach all 300k potential customers. Would the business be as interesting if you reached 10% of potential customers – 30k – and had 300 of those convert to paying customers?

The take home

This is an extraordinarily valuable exercise, because instead of hand-waving about business models down the road, you’re forced to think through your assumptions.

I see waaaaay too many entrepreneurs who fall in love with their ideas without taking an hour to ballpark some numbers and figure out how viable their *business* is, instead of how cool their product is (and I’ve been guiltier than most)

Once you understand the explicit assumptions you’ve made about how your biz will make money, you can decide whether to move forward with validating your customers’ problems and testing your solution.

Next: figure out how you’ll acquire customers.

Who this is for: hackers who have an in-depth understanding of the important problems their customers have. (If you’re not sure about this, read Why only fools write code first.)

Why you should read it: so you can figure out what to build, and have customers commit to pay you money before you write a line of code.

Once you understand the specific problem you’re solving, have a sense of why prospective customers want their problem solved and how much it’s worth to them, it’s time to validate your idea by finding the smallest solution possible that your customers would pay for.

This does not mean you should start writing code.

Remember: your goal is to NOT WASTE YOUR LIFE. There are faster ways to figure out how to validate your solution is worth paying for than writing code.

I’ll briefly touch on some of the downsides and upsides of delaying writing code, since changing the way you do things is rarely easy.

Then I’ll talk about how we validated our solution at SocialWOD, and got commitments from customers to pay us before we wrote a line of code… and how YOU CAN TOO.

The Hard Part About Delaying Writing Code

The downside of talking to customers first is that it’s out of your comfort zone, and sometimes it’s just a pain in the butt. Scheduling, missed appointments, etc take time. It can be tough to paint a complete picture of what customers want with qualitative data. In some respects, it’s the opposite of code: messy and uncontrollable. It can seem like you’re not making progress, because you’re used to progress meaning new features.

During this process we were tempted to say “screw it” and hit up Textmate to start banging out code, but we resisted that temptation, having gone down that road in the past only to waste our lives building something few people wanted.

Dealing with the downsides takes practice, discipline, and emotional energy. It’ll feel painful at first, but once you’ve gone though it once, it’ll feel a lot more comfortable.

The Upside Of Delaying Writing Code

You only build stuff people want, ergo, you don’t waste the most scarce resource you have: your time and attention. You have commitments to pay you money before you launch. You push your comfort zone and become a more powerful hacker than you once were. You come closer to controlling your own financial destiny.

If you’re not in this to learn more, build something people use, and / or make more money, what are you in this for?

Figure out Problems, and Then Find a Solution

The whole time you’ve been speaking with customers, you should be hearing recurring themes about problems they have. Until you truly understand their problems, you don’t truly understand the key parts of a solution that will solve their problem.

When we were building SocialWOD, we talked to 20-30 gym owners about the key problems they have with their business before we knew enough to build the smallest solution that could possibly be useful (i.e. worth paying for).

Once you understand your prospective customers’ problems is when you use your 1337 hax0r skills to figure out how you can solve their problems in an elegant way using technology.

A solution for our customers

At SocialWOD, we kept hearing that gym owners biggest problems are classic ones that almost every small business has:

1. Getting more customers
2. Keeping existing customers
3. Saving time

When we combined that with our CrossFit industry knowledge, we figured out that we could build a workout-tracking tool that would help gym owners with *all* of their problems (this is one thing I’ll change about my next business – our app is less attractive than one where the value prop has one clear benefit, i.e. “Use this and you’ll get N new customers a month”, or “Use this and you’ll cut down churn by 25%”).

A brief digression on how CrossFit works so you’ll grok our solution: every CrossFit gym around the world has a whiteboard. When you go into a gym, the workout of the day (or WOD), is written on the board. You do the WOD, and then write your name and score up on the board. Since you can’t see progress without tracking, athletes track their scores using – gasp – a paper training log kept at the gym, or a web or mobile app. We learned 10-20% of athletes care enough to use a web or mobile app – the data geeks and hard-core athletes.

With some secret sauce on our end, we figured out how a gym owner could snap a photo of their whiteboard at the end of the day, email it to us, and we’d put every athlete’s data online for them to use.

By having every athlete’s data tracked, SocialWOD could do things like:

1. Show *every* athlete AND gym owners an athlete’s training log and progress, without them having to do *any* work (other than, you know, the workout 🙂 ). Athletes get to see charts and graphs detailing their progress, and gym owners can help people along and congratulate them when they make big gains. (or, “Keep existing customers”)
2. Alert the gym owner know when an athlete hadn’t been to class in 30 days (if their name isn’t on the whiteboard they didn’t attend class). He can give the athlete a call to make them less likely to churn out (the LTV of an athlete to a gym owner is, depending on the monthly price an athlete pays, $1500-2500. So it’s worth it to make those phone calls).
3. Boost word of mouth marketing by posting athletes’ scores to Facebook for them (which CrossFit athletes already do anyways – we’re just making it easier by doing it for them)
4. Automatically post a gym’s scores to their Facebook page and blog, creating a stronger center of gravity around the gym’s communities outside of the gym (community is a HUGE part of CrossFit)

So! That was the big vision.

The Smallest Solution Worth Paying For

But instead of building that, we wireframed the core of app, along with parts of the bigger vision that we thought would be valuable to gym owners.

We hypothesized that the smallest thing that could possibly work was these two screens:

One we had these wireframes, we set up Skype calls with the folks that had shown strong interest to see if we were right.

In those calls, we:

• Validated their problems to make sure we were on the right track (“we found that most gym owners were looking to get more customers, keep existing ones happy, and do it while saving time. Does that sound right?”)
• Showed them the two key wireframes, and the other ones that would come “at some point down the road” (use Adobe Connect or join.me for dead-simple and free screen-sharing)
• Asked if “they could imagine using something like this at their gym” (or if they obviated the need for that question and asked us about pricing right after the wireframes, implying that this was something they’d use), we tested out pricing and asked for a commitment: “Pricing will be based on how many athletes you have at your gym. It’ll likely start at $50/month for 1-50 athletes and go up from there. We’re offering discounted pricing of $30/month to those who commit early, and we’ll start building once we get a certain number of commitments.”

We had decided not to start building until we got five commitments to pay – this was the validation we needed that we had solved a valuable problem. We ended up getting closer to 10.

Five was good enough for us to start building, but it might not be for you: choose a number that gives you a sense of whether you’re accurately validated your problem & solution.

These customers (“earlyvangelists” in the Lean Startup nomenclature) bought into the large vision, but decided that a two screen SocialWOD was worth paying for. Since we launched in late July 2011, we’ve regularly added features to fulfill the product vision, making it attractive to customers who need more features for them to try it.

Aside: keep in mind you may not get a positive response to your solution. In this case, you can integrate the feedback and iterate on your solution, and/or go back and better understand the problems your customers have.

A friend mentioned to me “I’d feel guilty building a two-screen CRUD app and charging people money for it!” I know what he meant, but also realized that as developers, we sometimes get caught up in the code and lose sight about what a business is supposed to do: solve a problem valuable enough that people pay you for it.

What Next

Even though you know what to build, there’s a couple more things you should do before you start writing code:

1. get a sense of the financial mechanics and potential upside of your business
2. figure out how you’ll acquire customers

I’ll cover these subjects in the next two posts.

If you don’t know Stripe, you should. They’re the easiest way to bill customers with your web app.

Ryan and I run SocialWOD out of Vancouver, Canada, but Stripe’s not available in Canada yet.

So we use Paypal.

And we hate Paypal.

I’ll spare you the play-by-play. But we’ve been rejected twice for Website Payments Pro with no explanation, getting our Paypal account connected to a bank account has been a nightmare, and to add insult to injury, the Paypal sales team continues to send us email to buy their products.

Things got so bad with Paypal that Ryan forwarded Stripe one of our email chains with Paypal as comic relief, exhorting them to get to Canada soon.

We didn’t want to get set up with another Canadian payment processor as we’d just switch to Stripe when they launched in Canada, so we decided to see if we could get set up with them today.

Turns out we can, even though we have a corp registered in Canada, not the US.

There’s one caveat though: you need a Social Security Number. So if you haven’t worked in the US, I think you’re out of luck.

Here’s how to do it (the usual caveats apply – I am neither a lawyer nor an accountant, so please get your own advice):

1. Get an Employer Identification Number from the IRS.
You can do this over the phone (phone number at link above) and the actual process takes 5-10 minutes. They’ll give you your EIN over the phone, but they also mail you a paper copy of your EIN which will take a couple weeks to get to you. (Also, to avoid paying US taxes, you’ll need to file a W8-BEN form. But you can do that later.)

2. Apply for a US bank account.
You can do this over the web at Harris Bank, a subsidiary of Bank of Montreal. A lot of US banks make this difficult – you have to go to a physical branch to open the account – but Harris lets you do it over the web. Plus, they’re used to dealing with Canadians who want to open US accounts.

You’ll need:

• Articles of Incorporation
• EIN (paper copy)
• Valid form of ID for each signer (driver’s license, passport, etc.)
• Proof of personal address for each signer (utility bill, bank statement) issued within past 90 days
• Proof of business address (utility bill, bank statement) issued within past 90 days
• Verification of deposit (signed by a signer and banker)
• Mother’s maiden name for each signer
• Home phone for each signer
• Social insurance or social security number for each signer

2a. If you don’t have a US mailing address, get one.
You’ll need one for the next step.

3. Sign up for Stripe.
This is where you’ll use your US address and Social Security Number.

4. Be ecstatic about working with a company that cares about its customers and is easy to use.

I ran this by Stripe and John Collison (one of Stripe’s founders), replied:

Yeah, with this you meet all the requirements to set up an account
with Stripe, so we’d love to have you aboard!

Hope this is helpful – we’re waiting for our EIN to arrive so we can SAY GOODBYE TO PAYPAL!

Who this is for: hackers who have an idea.

Why you should read it: so you don’t waste your life by building something nobody wants.

I have a confession to make: I’m 35, and until last year, I started building companies by creating a product.

Last year, when starting SocialWOD, my biz partner Ryan refused to write code without first talking to 20+ customers and getting commitments to pay us money for a solution to a well-defined problem of theirs.

Having gone down the “build first” path enough without significant success, I was up for trying a new approach. Conceptually it seemed to make sense that we’d be able to better solve our customers’ problems if we understood their problems better.

To boot, we decided not to build until we had verbal financial commitments from customers for our proposed solution.

The result? We were able to charge money from day one for a two-screen CRUD app. We were able to do so because we had honed in on a specific problem worth paying for, and we had financial commitments before we wrote a single line of app code.

Read on for some of the hard-earned lessons that’ll help you grow your biz.

Don’t build first

Building first puts you at a disadvantage. Here’s why:

Your job as an entrepreneur is to increase the odds that your business will succeed. Put another way, your job is to reduce the risks that prevent your venture from succeeding.

There are several types of risk that can kill your company.

Big ones include (but aren’t limited to):

– Team (are *we* the right people to execute)
– Market (do people want to buy it) ← usually the biggest risk
– Technology (can we build it) ← most hackers start here. Oops.

I’m gonna talk about why most hackers start reducing the technology risk (by building a product) when they should start by reducing the market risk.

And I’m going to give you a script you can use in interviews to learn more about the market side of your biz.

Why people start with code

Writing code is the fun part. Code can be bent to your will to do what you want it to do. You know when it works, and when it doesn’t. It’s clean.

People have an innate desire for control, and code can be controlled.

Code is your comfort zone, so it’s what you (and I!) fall back on.

But since you can build almost certainly build the solution, it’s almost always the wrong place to start.

Where you should start

“A hacker who has learned what to make, and not just how to make, is extraordinarily powerful.” – Paul Graham

You should start by understanding your market.

This is vague. More precisely, you should understand:

• who your customers are
• the specific problem your potential customers have
• why this is a problem for them
• how painful this problem is for them
• what happens when the problem is not solved
• how they are currently solving this problem, and what else they’ve tried
• how much this problem, when solved, is worth to them
• how they find out about solutions to this problem
• the words your customers to describe this problem

The best way to do this is by talking to real live people: picking up the phone, going out to coffee, etc, asking good questions, and listening.

For most hackers, talking to customers to figure out their unmet needs is scary, and always messier than code. It’s out of your comfort zone.

The rational response is “Righty-o! Talk to customers first – that makes sense.”

The emotional response is “Oh shit. Who should I talk to? What should I say? Won’t I just be better off building this feature?”

The way I overcome this emotional trauma is to think about the insights I’ve gleaned from talking to customers in the past, and more importantly: how much time and frustration these conversations have saved me. Hackers hate working on stuff nobody uses.

Really, it’s simple: the fastest way to build something people want is to understand their problems. And the fastest way to understand their problems is to listen to what they have to say.

OK, how can I go about talking to customers?

Find some potential customers.

I may go into this in a future article, but finding a few individual customers in your market should be easy.

What should I say?

Here’s an template of an email we used at SocialWOD when referred to potential customers (we make software for CrossFit Gyms)

Hi First_name,

I spoke to referrer_full_name at referring_gym_name recently.

He said you might be interested in sharing some insights about problem_we’re_solving, and hearing about what we’ve learned talking to your peers.

I’m not trying to sell anything – just looking to learn about your business’s problems so I can build something that helps you grow your business.

Cheers,

your_name

The keys to this email are:

1. You’re promising to provide value (share some insights)
2. You want to help them grow their business
3. You’re not selling anything

Smart Fast Startup has a great cold-calling method to validate whether your idea solves a problem that people want to pay for.

This should get you a few meetings.

What to say in your meetings

Your goal with these meetings should be to hone in on answers for each of these:

• who your customers are
• the specific problem your potential customers have
• why this is a problem for them
• how painful this problem is for them
• what happens when the problem is not solved
• how they are currently solving this problem, and what else they’ve tried
• how much this problem, when solved, is worth to them
• how they find out about solutions to this problem
• the words your customers to describe this problem

Let’s say you had an idea about product for movie theater owners that would pipe buttered popcorn (and other) smells into theaters to help drive concession sales.

Here’s the sort of questions I would ask a theater owner:

Question	Trying to learn
Tell me about your business. What are your biggest problems? What keeps you up at night? Why?	What are the big problems they have in their biz? Why are they problems? What happens when those problems aren’t solved?
What are the key metrics that drive your business?	What are the key levers in their biz – concession dollars per ticket sold? straight up ticket sales? etc. Is your solution potentially a must-have or a nice to have?
(if they don’t mention concessions) What impact do concessions have on your business?	Is your solution even potentially valuable to them? How much, or why not? (Make sure you understand this. Keep unpeeling the onion; make sure you understand this fully. Try not to make assumptions here.)
Have you looked at anything to help you with this problem? How have they worked for you? Where did you find them?	Learning what else is out there? Are those solutions working, or not? What distribution channels might you need to be in?
I have some ideas about products that might be useful. Can I give you a 1-liner description and you tell me if we’re crazy or may be on to something?	This is to get a sense of whether your idea may even be valuable to them… you don’t want to get into specifics really, just tease them and get high-level feedback.

Also ask:

• Is it ok if I follow up as we develop our ideas? (I’ve never had anybody say no to this)
• Is there anybody else who you think we should speak to who have the same kinds of problems you do? (these are the people you call next)

The goal with these interviews is to *listen* and *learn*, not to sell. Learn where you’re right, where you’re wrong, what words your customers use, what big problems they have, and how you can adapt your solution to solve those problems.

After a couple interviews you’ll be able to provide insight and become valuable to the people you’re speaking with, which makes you
even more trusted (“oh we just spoke to person XYZ at ABC corp… he was feeling the same pain, you’re not alone!” OR BETTER “just spoke to XYZ at ABC… he solved the problem you’re facing by doing 123”.)

And after 10-20 of these you’ll know a crap ton more about your market, and whether this is a problem even worth your time.

This process isn’t easy. But recurring themes will emerge that will help you hone in on a problem worth solving without writing a single line of code. The reason you do this first is because you need to do this whether you write code. You might as well do this before you spend a few months writing code, so you can figure out what to build.

Now that you better understand the problem and market, the next post will cover what you can do with that information (hint: it’s not “build the product”).

In 2008, I left FOX Interactive Media to join up with Jon Bischke to start eduFire.

It was the first foray into running a venture-backed startup for both of us, and we made a lot of mistakes (I’ll talk about some in another post.)

In the course of raising a $500k angel round, and laying the groundwork for an institutional round (which ended up being ~$1.2M, led by Battery Ventures), we spoke to a crap ton of angels and institutional investors in LA (where we were based) and the Valley.

Four years later, one meeting in particular stands out.

It was with Mike Maples, who despite being fairly new to investing in the Valley, had invested in companies like Twitter and Digg.

He was a nice, humble, and smart guy. It was one of the most valuable meetings we had, for a lot of reasons. You’ll see the biggest reason in a moment.

We pitched Mike on our idea: eduFire was an education marketplace, where you could find teachers of any subject you wanted to learn. Students would be able to learn from experts, and teachers would be able to earn a lot more than they currently did.

“Education,” we said, “is a $1T market. Yes: trillion.”

The most common response we got from investors was “that sounds interesting, but I don’t know much about education…” (Turns out we were early – education is so hot right now, but it wasn’t in 2008.)

Mike gave a similar response.

But then he said something interesting.

Something like:

“You know, I heard about a really interesting company the other day. They’ve approached building their business in a really cool way. They started by identifying the riskiest parts of their business. Then they tested their theories about how to reduce those risks in the real world. They’ve been at it for a short while, are learning a ton, and have removed all kinds of risk from their business. It’s based on a book called Four Steps to the Epiphany. Have you guys heard of Steve Blank…?”

The company was IMVU, co-founded by Eric Ries. Ries has gone on to write a book and lead the Lean Startup movement, based on his experiences growing IMVU.

After the meeting, Jon and I briefly discussed this crazy new risk-reduction approach. We never acted on it, other than trying to get through the dense and academic Four Steps to the Epiphany. Continuing to build was a much more fun and comfortable route to take. (And I’m still not sure why we didn’t ask Mike for an intro to Steve or the IMVU guys – Jon and I both like meeting, learning from, and helping smart folks. Life might have taken an even more interesting turn had we made one of those connections.)

Mike passed on eduFire, we closed our angel round, and continued on the path of building our vision.

I left eduFire in 2009, and after raising their round from Battery, it was sold in 2010 to a company that wanted the tech.

That meeting with Mike stayed with me, though. It took a few years – and a few more “let’s build the vision” approaches and ensuing failures – before the lesson that you should identify and reduce a new venture’s biggest risks FIRST was driven home.

This is one of the valuable lessons about building a business that I’ve learned along the way, but there are many more. (It’s also where this blog’s tagline comes from: “I’d rather learn I’m wrong than waste my life.”)

It’s almost like when I started eduFire, I had a heavily pixellated mental map of how to grow a successful business. It looked something like this:

It’s gotten sharper over the years, and it’s my hope that by continuing to run a business (SocialWOD), help others run theirs, talk to people smarter than I, and share the lessons I’ve learned, my – and your – map will come to look more like this: